BROOKLYN-49: Catalogue persistence

Brooklyn persists catalogue entries and loads them when rebinding.
* Most interesting are the changes to `AbstractManagementContext`, `RebindManagerImpl` and `BasicBrooklynCatalog`.
* Catalogue persistence tests are in `RebindCatalogItemTest`.
* See the comments in 5212980 for the interesting bits.
* Catalog persistence is off by default and enabled with the `--persistCatalog` command line flag.
* There is not (currently) an option to enable catalogue persistence but to load the catalogue from a file. It would be fairly straightforward to add.

Note that most - maybe all - catalogues are currently written like:
```
<catalog>
    <template type="brooklyn.clocker.example.DockerCloud" name="Docker cloud">
        <description>Launches a Docker cloud</description>
        <iconUrl>http://localhost:5642/docker-whale.png</iconUrl>
    </template>

    <classpath scan="annotations"> 
        <entry>file://~/.m2/repository/io/brooklyn/clocker/brooklyn-clocker-docker/0.6.0-SNAPSHOT/brooklyn-clocker-docker-0.6.0-SNAPSHOT.jar</entry>
        ...
    </classpath>
</catalog>
```
The template will be persisted but the classpath will *not*, and thus it will not be possible to use such entries after Brooklyn has rebinded.

Entries must be written in this format instead:
```
    <template name="Entity name" type="com.example.ExampleApp">
        <description>An example application</description>
        <libraries>
            <bundle>file://path/to/bundle.jar</bundle>
        </libraries>
    </template>
```
I've tried to be as thorough as I can, but please review carefully!
I'm a bit confused here. If the feature is enabled (i.e. `persistCatalogItemsEnabled`) and the catalog mode is `LOAD_BROOKLYN_CATALOG_URL`, then we log.info about ignoring the persisted catalog but we don't change the persisted state at all. I can kind-of see why (it's like starting with persistence disabled for the catalog).

However, it gets confusing because modifications to this catalog will be persisted. Those modifications might conflict in some way with the already-persisted state.

Conclusion: I think we need a clearer indication of what to do with the catalog. What are the use-cases? How many of these are we supporting?
* no persistence; just catalog.xml
  (i.e. `--persist disabled` from CLI)
* if there is persisted state, including catalog, then use it
  (i.e. `--persist auto` and set property `persistCatalogItemsEnabled` to true)
* if there is persisted state, but there is no persisted catalog (e.g. customer has never turned on this feature before), then populate it from catalog.xml
  (i.e. `--persist auto` and set property `persistCatalogItemsEnabled` to true)
* use persisted state, but not for the catalog (i.e. just use catalog.xml)
  (i.e. `--persist auto` and set property `persistCatalogItemsEnabled` to false)
* override the existing persisted catalog with the contents from catalog.xml
  (not currently supported? suggest we ignore this)