Restructured and fixed up handling of --update and --deep

I noticed some inconsistencies with these options (as well as --noreplace and --newuse) when working on !173 (merged).

More or less, the issue was that --noreplace (which is also implied by --update and --newuse) would cause the dependency calculation to act as if no packages were passed explicitly on the command line. The expected behaviour is that packages passed explicitly are always rebuilt unless --noreplace is used, so that works, however one purpose of --noreplace is that when using --newuse or --update, packages won't be rebuilt unless they need use flag changes, or updates, respectively. Unfortunately, since --noreplace means that we don't track which packages were passed explicitly, it means that any time you pass --newuse or --update it would apply flag changes or package updates to all packages, whether or not they were specified by the user on the command line, something which makes more sense in the context of --deep (which at this point is doing very little).

To simplify things, and since I don't think there are really many use cases for using --newuse, --noreplace and --update independently of one another, I've merged the flags together into --update, leaving the command line options for the other two to avoid breaking the interface, but they all now alias to --update.

FIXME: Help messages for --newuse and --noreplace should be updated to reflect this change.

I also fixed up how --update and --deep work, so that now, --update only affects the packages passed explicitly, and --deep extends updates to all installed packages.

I also made two performance improvements:

1. When --deep isn't passed, we don't load dependencies of installed packages into the dependency calculator (since they shouldn't change). Packages passed explicitly (for rebuilds, or new packages) still have their entire dependency tree loaded into the calculator since we don't know until the end of dependency resolution how deep into the dependency tree we're going to need to go to install packages (sadly, this is a limitation of the MaxSAT-based dependency solver. A custom backtracking solver might get better performance, but would be more complicated to write).
2. Blockers (packages marked as conflicting with a package) are no longer pulled into the dependency calculator (unless something depends on them). This can significantly reduce the size of the dependency tree (and thus improve dependency resolution speed) if there are a lot of blockers.