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 question whether there is a benefit having `CatalogItemDto` extend `CatalogItem` - i.e. should anyone accessing this code ever see the DTOs or only the domain objects (DOs)? So does this just make it more complicated?

I did wonder if `CatalogItemDtoAbstract` is serving almost the same purpose as `CatalogItemMemento`, but I think it is different: the former is for deserializing/serializing the catalog.xml, while the latter is for persisted state. Currently they have different formats but perhaps they should converge!