[WIP] World Generator API

World Generator API introduces the pieces required to represent the various aspects of the world generator. It adds interfaces for:

- `WorldGenerator`, the chunk provider which contains the actual generation process
- `ExtentBuffer`, this is a representation of an area's block data which is detached from the world and this is lightweight when modifying large amounts of blocks, such as during generation.
- `Populator`, which is a feature or aspect of the world which is layered on after the initial terrain generation, these perform actions such as replacing biome-specific blocks and placing structures (aka. `PopulatorObjects`, see below).
- `GeneratorPopulator`, which is similar to the `Populators` but is applied during the actual generation phase rather than the population phase. These apply themselves directly to the `ExtentBuffer`, and thus are suited for high intensity operations.
- `PopulatorObject`, this represents a specific structure or object used by a `Populator`.
- `BiomeManager`, this is the generator which decides in what configuration the biomes are laid out into the world.

Methods were also added to `Server` for loading, unloading, and creating worlds, and to `World` for loading, unloading, and generating chunks.

In addition several events were added:

- `ChunkPreGenerateEvent`, signals that a chunk is about to enter the generation process.
- `ChunkPostGenerateEvent`, signals that a chunk has just finished the generation process
- `ChunkPrePopulateEvent`, signals that a chunk is about to begin the population process, also includes an ordered list of populators which are about to be applied to the chunk.
- `ChunkPostPopulateEvent`, signals that a chunk has just finished the population process and is now considered complete.

Still todo:

- [ ] `WorldStorage`, Representing world data in the format of the persistence API, I'll be working with @gabizou to implement this.
- [ ] `ChunkStorage`, similar to the above.
- [ ] an asynchronous method for getting a list of generated chunks from the `WorldStorage` (https://github.com/SpongePowered/SpongeAPI/issues/256)
- [ ] Add a `LightingManager` to handle the calculations of initial lighting levels.
- [ ] Registration mechanism for registering custom generators, biomes, and populators (**Needs Discussion**)
No, please don't do that. Googles and Apache Commons `ImmutableList`s and others explicitly prevent extending of that to ensure that something `Immutable` stays immutable at all times.

> **Note:** Although this class is not final, it cannot be subclassed as it has no public or protected constructors. Thus, instances of this type are guaranteed to be immutable.

The quote above is from `com.google.common.collect.ImmutableList``s javadocs

> It makes passing around buffers easier 

If there are simply no setters then just remove the `Immutable` prefix  and you don't cause any confusion that something immutable may be mutable in some cases.

> while still implying that there is an underlying immutable view of every block buffer.

But that's the point: The underlying view may NOT be immutable.