[Scenario] Add policy to prevent Remove from repositories

nasa/MCT-Plugins#135 specifies containment rules which
must be met for Activity Type and Tag objects, including
that these must be contained in exactly one repository.
Adding policy to prevent their removal (via Remove
Manifestation) from repositories is a first step in
resolving this issue.
[Scenario] Expose remove-from-repository policy

Expose, at the plug-in level, the policy prohibiting removal of
objects from Repositories.
[Scenario] Simplify remove-from-repository policy

Removes unnecessary conditional branches, reduces
policy decision to logical operation.
[Scenario] Class-level javadoc for removal policy
[Scenario] Add create wizard UI for tags

Adds a create wizard UI for tags. This is the same
as the default create wizard, but allows for future
addition of logic to ensure tags always show up in
the User Tags repository upon creation.
[Scenario] Fix bundle reference in tag wizard UI
[Scenario] Add decorator for repository save

Activity Type and Tag components created via the Create
menu need to appear in specific repositories by default.
The added class can be used to decorate their wizard
UIs to ensure that this happens.
[Scenario] Add class-level javadoc to wizard decorator
[Scenario] Add missing constructor to wizard decorator
[Scenario] Store types/tags to repos on creation

Use RepositoryWizardDecorator to ensure that any
created activity types or tags also are placed in the
appropriate repository for these objects at the
time of creation.

Simplify the decorator itself to make use of the
fact that createComp occurs while a group of related
database operations is already underway.
[Scenario] Remove unused imports
[Scenario] Move Repository impl to shared superclass

Moves bulk of logic/behavior associated with Tag and
Activity Type repositories to a common superclass.
This should simplify subsequent implementation of
move-instead-of-copy behavior when dragging into
repositories.
[Scenario] Class-level javadoc for repository components
[Scenario] Remove components from other repositories on add

When a component is added to one repository (such as
via drag and drop), remove it from all similar repositories.
This ensures that a component exists in no more than
one repository at any given time.
[Scenario] Move components between repositories on SwingWorker

Use a SwingWorker to handle the move of components between
repositories in the background. Additionally, move this
logic out of RepositoryComponent in order to simplify parts.
This also provides a place to display the dialog associated
with this move, which is also specified as part of
nasa/MCT-Plugins#135.
[Scenario] Stub in repository move warning dialog
[Scenario] Add progress bar to repository move dialog
[Scenario] Fix bug in removal portion of repository move

Moving multiple components between repositories would
sometimes fail because getReferencingComponents may
return new versions of parent objects, which were
being used as keys to a map in the removal procedure.
Changing to track parents by ids, and maintaining the
most recently-returned version of each parent.

Additionally, clarify some variable names and fix
some logic in progress reporting.
[Scenario] Disable OK button during repository move

It is important to block user interaction while
the repository move is being completed, in case this
is over a higher-latency connection (calls to
getReferencingComponents consult the database, so
it may take time to complete the operation), in
order to avoid presenting the user an intermediary
state.

Additionally, replace the progress dialog with a
notification (currently a placeholder, will contain
information about which components have been moved
from or to which repositories)
[Scenario] Show summary of components moved in dialog

When moving components between repositories to enforce
the exactly-one-repository-per-component rule (as
specified in nasa/MCT-Plugins#135), notify the user
of the specific changes so that they have an opportunity
to undo them.