Preferences for Multiple Instances, Applications, and Versions

Regarding Preferences support for Multiple Instances, Applications, and Versions

Right now, Prefs are stored in the userRoot() by Class and name.

I don't think that this allows us to support any of these scenarios:

```
multiple applications (that use the application framework)
multiple versions of the same application
multiple instances (contexts) of the same application
```

I all of these cases, they will stomp on each other by reading/writing the same Prefs.

I'd like to propose an extension to the Prefs mechanism which follows:

When an application launches, if it does not find a node for itself (applicationA/v2.0), it could optionally copy or translate the values from an old version node (applicationA/v2.0). The Prefs class could provide some helper methods for this. The Prefs nodes could be something like this:

userRoot()

```
/applicationA

/v1.01

/...

/v1.02

/...

/applicationB

/v2.0

/...
```

To deal with multiple instances (contexts) of the same application, it might make sense to have the prefs stored by context (perhaps under a node for application and a node for each version. It seems that each instance would need to have an identifier, and this identifier would need to be set when the app. (re-)launches, perhaps using a command line argument.

While less common, the ability to have multiple instances (contexts) of the same application can be useful in two use cases I can think of: 1) running instances running headless on a server, 2) having multiple users of an application on the same OS user account (like 'guest'). A context identifier would also enable separate prefs settings for these situations.

Using context identifiers, perhaps the Prefs nodes could be something like this:

userRoot()

```
/applicationA

/v1.01

/...
/cID1

/...

/v1.02

/...

/applicationB

/v2.0

/cID1

/...

/cID2

/...
```

For example, if a context identifier is provided, the app. would use the nodes under /applicationA/v1.01/cID1... and if a context identifier is not provided, the app. would use the nodes under /applicationA/v1.01/...

Perhaps Prefs could be Contextual, and then use getTitle(), getVersion().
(For the context, I suppose one kluge would be to add something to the Title...)

There may be some related issues, e.g. in ConfigFileParameters, this is hardcoded: CONFIG_FILE = "ImageJ.cfg";

Migrated-From: http://trac.imagej.net/ticket/1706

Start by locating the Prefs mechanism, userRoot(), and ConfigFileParameters, including its hardcoded CONFIG_FILE value of ImageJ.cfg. Review how getTitle() and getVersion() are used, then determine the project's preferred model for separating applications, versions, and contexts. Done should mean the scope and behavior are agreed, implemented, and covered by relevant tests.

Written by the indexing model from the issue text.