Bundle registry: Cleanup/clarify bundle installation

Management of bundle installs/upgrades was a mess, this attempts to
clean it up and sort it out.

It was not clear under which circumstances a bundle should be installed
via the bundle object vs via the bundle registry. The logical answer here
is that it should be done by the registry, so document why that is the case.

In bundleregistry, upgrade() seemed like it should be used for bundle
updates, but actually install() duplicated some of that logic in a slightly
different way. Touch up the upgrade logic in install(), remove upgrade(),
and add some documentation to make the situation clear.

The install() API differed between JournalEntryBundle, ActivityBundle and
ContentBundle. Eliminate the differences. JEB uid's are now stored at
initialization time, and the Bundle classes themselves choose the install
path (this does not vary when activities are installed this way).

The journal had two codepaths that dealt with activity installation/upgrade
(on arrival of the bundle in the datastore, and on resume)); unite them into
one and update for the above changes.
bundleregistry: Fix conflict between file monitoring and its own operations (#3707)

When an activity is installed via bundleregistry, it is effectively
registered twice: once by bundleregistry after installing it, and again
when the file operations monitor picked up the event.

This lead to error messages in the logs and occasional duplication
of activity icons in the home view.

Refactor the code slightly so that it is resilient and accepting that
some activities may try to be registered twice. To avoid the duplication
of icons, be more careful to only emit the bundle-added signal when we
really add the bundle.

Also clean up the installation of MIME types. The ActivityBundle class
does this, so there is no need for bundleregistry to do so.
Store content bundles in bundle registry

Previously, only activity bundles were maintained in the bundle registry.
Extend this to cover all kinds of "trackable" bundles, which in reality
just means the addition of content bundles.

This is needed in order to clean up the code and bundle API (as has happened
here) and to allow content bundle updates through the updater control
panel.