XD-1477 Merge Container & ContainerAttributes

- Rename `ContainerAttributesRepository` with `ContainerRepository`
  - Also, `ZooKeeperContainerAttributesRepository` to `ZooKeeperContainerRepository`
- Remove existing `ContainerRepository` that returns the containers iterator
  - Use the newly added ContainerRepository as the dependency instead.
- Compose `ContainerRepository` into `DeploymentSupervisor`
  - Update all the dependent listeners to use this container repository
- Move ContainerAttributes into Container
- Create `ContainerResource` REST domain resource that holds ContainerAttributes
- Update Runtime container command operations
- Fix tests
The change in this one line (which allowed the removal of the `wrapAsIterable` method below) makes the code so much cleaner! Unfortunately, this change makes stream deployment much slower. Here's the reason why:

Previously the code read like this:

```
wrapAsIterable(containerRepository.getContainerIterator())
```

The method `getContainerIterator()` was implemented like this in `DeploymentSupervisor`:

```
/**
 * {@inheritDoc}
 */
@Override
public Iterator<Container> getContainerIterator() {
	PathChildrenCache cache = containers.get();
	return cache == null
			? Collections.<Container> emptyIterator()
			: new ChildPathIterator<Container>(containerConverter, cache);
}
```

As we can see, this iterator was iterating over a cache. Now the proposed change looks like this:

```
containerRepository.findAll()
```

And the implementation in ZooKeeperContainerRepository:

```
@Override
public List<Container> findAll() {
	List<Container> results = new ArrayList<Container>();
	try {
		List<String> children = zkConnection.getClient().getChildren().forPath(Paths.CONTAINERS);
		for (String id : children) {
			results.add(findOne(id));
		}
		return results;
	}
	catch (Exception e) {
		throw ZooKeeperUtils.wrapThrowable(e);
	}
}

...

@Override
public Container findOne(String id) {
	Container container = null;
	try {
		String containerPath = path(id);
		byte[] data = zkConnection.getClient().getData().forPath(containerPath);
		if (data != null) {
			Map<String, String> map = mapBytesUtility.toMap(data);
			container = new Container(Paths.stripPath(containerPath), map);
		}
	}
	catch (Exception e) {
		throw ZooKeeperUtils.wrapThrowable(e);
	}
	return container;
}

```

Now let's say we want to deploy a 4 module stream to a cluster of 10 containers. Using the repository this means we have:

* 1 network call to list the containers
* 10 network calls to obtain the container attributes (1 per container)
* Repeat the above 4 times - once for each module

This results in a total of 44 network calls to obtain the list of containers we can deploy to. Previously this required 0 network calls since the container list and data were stored in a cache.

That being said - the abstraction of a container module being separate from the deployment supervisor is **absolutely** the right thing to do in terms of architecture. The challenge is making this change while making sure we don't introduce bottlenecks into the system.

Perhaps we can put some thought into the `ZooKeeperContainerRepository` implementation to see if it can cache the container list so that we can repeatedly invoke `findAll()` without suffering the consequences indicated above. The question is whether we should do that here or in a subsequent PR.