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!
Include a `TODO` at the start of this comment.
The original `catalog.xml` (and catalog structure) allowed for nesting of catalogs. I don't think anyone has ever used that. We should probably simplify the code until requirements for that kind of thing become apparent.