This branch reflects an effort to rework the main class of the Mamut
app: the MamutAppModel. The main goal is to make the app model the
core of a Mastodon session, and have all of its fields final, and
have them containing everything we need to run all featuures of the
app.

This is a WIP but so far we have:
- The windowManager is now a field of the app model.
- The app model is immutable: it cannot change under the user feet.
When a user loads a project, it gets another instance, but cannot
modify an existing one.
- And to do this, the main work of this PR is the rework of the project
loading and saving, detailed a bit below.

The ProjectManager class is gone, replaced by 4 classes with only static
methods, in the package org.mastodon.mamut.io. Each one takes care
about loading, saving, importing or exporting.

The loading methods all produces a new MamutAppModel instance. This
instance receives the MamutProject it was created on (handy to save
it later). The app model is properly initiatialized ONCE with
everything. Then a consumer can create a MainWindow to pilot it.

I have updated all the classes so that they compile. The tests all
run (except for the garbage collection from Mathias, which requires
changing two deps). But I am anxious to see if we cover all the use
cases below:

- [x] open a project
- [ ] save a modified project
- [x] 'save as' a project
- [ ] test that we can reload a saved project
- [ ] test that we can reload a 'saved as' project

The importers and exporters work, as seen by the tests, but I would like
to test them and rework their UI.
Then I will rework again the app model, rename it etc...

Also make more explicit their respective role in the javadoc.

We rely on MamutAppModel for non-view related fields.
Also, do not test for appModel == null anymore.

They will generate an error in v2.0.

This commit removes mention of the deprecated SetupAssignments and
BrightnessDialog classes. The actions that brought the corresponding
dialogs are removed as well.
There is some code to still make it possible to save/load bdv settings
and use ones that are generated 'elsewhere'.

Mainly as an effort to reduce the number of fields and methods
in the window manager class. We began with just a manager for BDV
and TrackScheme styles but now we have 5 of them. For now.
Also this will make it easier to extend Mastodon with
new views in the future.

The view lists are stored in a map, indexed by their class, like for
the manager. This diminish the number of fields and methods in the
window manager class.

This also allows for treating views in a general manner without
having to change too much code when a new view will be added.
For this I shall find a way to create view instances in a generic
manner, probably with a factory pattern.

We started with just 2 views (BDV and TrackScheme) but now there are
enough of them is that it is worthwhile having some generic way of
handling them. The next commits will be about coming with a sensible
way of doing it. Ideally, we want to make it possible for 3rd parties
to extends Mastodon with new views without having to recompile it.

- Get rid of IMastodonView and IMastodonFrameView
- An interface for views that have a ViewerFrame,
that MastodonFrameView implements.
- An interface for all Mamut views (branch and core graphs) that
extend from it, and add methods for GroupHandle on onClose().
- MamutView and MamutBranchView both implement this interface.

So that now we can have one factory type for both branch and core
graph views.
Tune the bdv factory accordingly.

Now we manage all views (branch and core graphs) within one field
with one set of methods.

TODOs:
- The selection table flag is not stored properly yet, because we still
rely on MamutViewStateSerialization for GUI state serialization.
- The context provider state serialization is not supported yet.

We may want to use class objects as keys when managing factories.

The window manager has now a MamutViews that is in charge of
detecting and managing a collection of view factories.

Each factory is then used by the window manager to make one action
that creates a view, registers it in the WM, deals whether it has a
context provider or a context chooser, notifies listeners of its
creation (see below) and finally shows it.

New views are created, registered and managed only via these factories
now. Which means that that window manager does not know of any
concrete view class. It just manages all the ones it found. This
will make it easier to extends Mastodon with new views, without
having to touch or even recompile the core.

This also makes the window manager class much shorter. There are much
less methods and much less fields, since all views are managed in a
generic manner.

The view factory are also nice because they contain in one place all
the info related to an action: command name, menu text, description.

For ELEPHANT, Ko requires that there is a view creation listeners list
for BDV window. I kept this, but made it generic. There is now one
listener list per view type. So you can register a listener for the
creation of any type of view, and get it befoore it is shown.

The factories also handle GUI state serialization. The ProjectLoader
and ProjectSaver class use these factories when loading / saving for
restoring / saving the GUI state. There are no specific hard-coded
code to handle serialization of GUI state in the io package. Well,
not entirely: we still need to know how to convert a Map< String, Object >
(which is the GUI state as understood by the views) to a JDom element,
which is what the MamutViewStateXMLSerialization does. It just has
a series of methods to convert any type or class used in GUI state
to a JDom-ready text.

This de/serialization also now takes much less code than before, as
there were a lot of duplicated code, wich is now present once in
the mother abstract class for view factories.

Also: the views are now decoupled from saving or restoring the GUI
state. The factory does it, which is cleaner.

The MainWindow class still needs to know of concrete view types,
because we still want to have buttons for the views, and have the nice
click and shift-click on them. I think this is ok
because normally the rest of the code is *almost* fully decoupled
from the MainWindow. There is still one static method addMenus()
that is called by the views to create the File menu. This could
be moved to the window manager, as it is as generic as the Window
menu.

This will make it easier also, to create new Mastodon commands or
plugins that do now show the MainWindow, but whatever a 3rd party
coder wants.

Some managers and page, the ones related to the view styles, are now
managed by a factory, like for the views. Has less impact than the views
but makes the views completely extensible.

Replaced by the bdv.tools.ToggleDialogAction class.

There is the pluginService.createInstancesOfType() that is very
concise, but I want to make it possible for a plugin to be
disabled, using the flat Plugin( type = ....class, enabled = false ).
In that case and with the new utility, the class is not instantiated
by the service, which makes it possible to use it "manually", or
disable unwanted plugin simply.

Remove the Mastodon CommandDescriptionProvider and replace by the
BDV-core equivalent.

These classes have been migrated in upstream repos, mainly the
BDV-core and ui-behaviour. We can remove them from Mastodon and use
the common ones, maintained elsewhere.

There are two adaptations specific for Mastodon:

1/ The KeymapManager class is extended by a specific one for Mastodon
so that we can load and save keymaps in the Mastodon folder, and so
that we load the builtin keymaps we had before.

2/ The new CommandDescription requires specifying a context AND now a
scope. I made two scopes: one for the actions that are generic to
Mastodon (everything in views, that do not know of the Mamut model),
and one specific for the Mamut application (everything under
org.mastodon.mamut, which is the one users have).

I also made a static method to create a ProjectModel, and hide the
creation of the KeymapManager and KeyPressedManager there.

I could not replace one class:
- KeymapSettingsPage: There is the equivalent in BDV-core, but it
does not 'see' the builtin keymaps we have in Mastodon.

During a discussion with @stefanhahmann
We don't need to store the values determined at startup, because
we can get them from the current shared BDV data. In theory this
makes it possible to have Mastodon views reflects changes in the
image data (even if we have no cases for it yet). Plus, it's shorter
and more elegant.
However, we will need to double-chek that everything is ok with
BDV files, ImagePlus and DUMMY image file format.

Offers common facilities to load / save user styles from /
to a YAML file. Since it is the only case in Mastodon we hope
to remove quite some duplicated code.

Remove plenty of duplicated code.

Ko made me realize that with slight deviation from what is expected
in a YAML file, Mastodon will crash with no recoverable exception.
This commmit introduces some methods to deserialize common core
values that gracefully trigger an exception, with a useful error
message. This exception is caught by the load() method of the style
manager, which handles them gracefully.

Before this commit, if the BDV XML file pointed to a missing image data
file (H5) or to a remote URL that cannot be reached, the launcher
would crash and block.
Now it generates an error message, and the launcher offers to open
dummy data instead.

- Interactive methods are now in LauncherUtil, not in ProjectLoader
any more.
- They do not throw any exceptions, but know how to return a user-
readable error message.
- The launcher uses these methods, and display the error messages
when something wrong happens.

The method is supposed to be called NOT on the EDT thread, will
still show dialogs on the EDT thread, and will return *only once
the project has been saved*.
This allows for waiting for the project to be saved before moving on.

And update it if the user saves the project under another name.
Partly addresses mastodon-sc#238.

And it and can update their title.

The dialog windows are stored in a separate list than from the view.
There is a method to run an action on all opened windows, dialogs
and mamut view.

After saving a project, all the opened windows update their title
to reflect the new name.
Fix mastodon-sc#238

But instead catch them and make an error message.

The FocusModel interface had an unneeded type. It does not need to
know the type of edges in a graph, because it does not work with a
graph, but with a simple collection.
Removing this superficious type triggered a lot of changes in the
code because we touched the signature of a core interface.
But not impact otherwise.

Imperfect because a full saving requires have a BDV view opened,
which is not necessarily our case. When we don't have a view
opened, save everything we can but no more.
Fixes mastodon-sc#230

It listens to programmatic changes in the color bar overlay, which
ensures the menu is in sync with what the colorbar is configured
with. This is important when restoring the GUI state.
Concomittantly: we have one class more, but we diminish the
duplicated code between MamutView and MamutBranchView.

Because we build it before regenerating the GUI state, the
TrackScheme transforms of the branch trackschemes are now
properly restored.

With the previous commits, fixes mastodon-sc#243

Before this commits, all the sessions launched with this class
failed to terminate properly.

If we don't wait a little bit, the BDV state, notably the
transform, is not restored properly. It is not enough to
just display the frame before restoring the transform.

We put the delay 0.1s in a separate thread not to block
the loading if we have many BDV views.

Fixes mastodon-sc#251

Doing otherwise causes a very weird bug, making Mastodon crash when
deployed in Fiji but not in Eclipse.

The reason for the crash is the following: When creating the
FeatureSpecsService, it immediately runs Specs discovery. For this
it needs the PluginService to be ALREADY initialized. This is the
case when running Mastodon from Eclipse, but not when running it
from Fiji.
Setting the priority to extremely low makes sure FeatureSpecsService
is initialized among the last, well after the services it depends on.

…to rework-app-model

So that we don't see warnings everytime we change a setting.

To separate pages made to configure views, from pages made to control
plugins.

I want to move and rename style files, without breaking things
for the user. This will simplofy this process.

- Number of incoming and outgoing links on a spot.
Useful to fish for cells that have a division or a merge, and debug
unwanted linking events.
- Oriented time-difference for links.
Useful to detect buggy links introduced by improper semi-auto tracking.
Debugging without this feature is really a pain.

when creating the table header and collecting values.
This is to protect against a bug that appear with features
that are not careful to always return the same set of
projections when the projections() method is called. This
happend for the link target feature and generated the bug below:
mastodon-sc#217

One can fix the bug by imposing the same order on features, but
it is also a plus to make the table rendering independent of
this order being preserved.

This feature relies oncode part of Mobie that have moved from
there recently. It will need to be reimplemented, using the new
changes in the N5 library (and friends) by the Saalfeld lab
(and friends).

Remote opening of BDV data on Big-Data-Servers still work.

- Remove dep imagej-legacy - It generated errors with the legacy
injector when trying to run Mastodon from Eclipse.
- Remove mobie-io, jackson-core - We have to re-engineer N5 and S3
support.
- Remove scijava-common, IO_ - Needed for DnD support, which needs
to be rewritten as well.
- Remove custom specification of bdv-core - It was ignored anyway
and we now rely on the parent ponm specification.

It is helpful if a plugin has access to a list of views.
Use case: https://github.com/elephant-track/elephant-client/blob/951a2c60115d30d9debae453436ddfbd40ac8042/src/main/java/org/elephant/actions/mixins/WindowManagerMixin.java#L55

The purpose of the getViewList() method now changed. It is meant
to be used by 3rd party consumers, not by the internal logic.