New way to store arenas

Early Pull-Request, all these things.

 - [x] `Arena` object
 - [ ] `ArenaManager`, save of these `Arena` objects in the config file.
 - [ ] Migration of the code to this new way of storing Arenas.
 - [ ] Update of the API.
 - [ ] Automatic migration from the old format to the new one.

-------

I think (to fix some tickets, and for maintainability) that it would be great to change the way arenas are stored.

My idea is simple, simpler than the current way it is done.

An arena is an object, let's say `Arena`, with all properties as attributes, and an UUID as an id (instead of the current numeric ID). This object implements the `ConfigurationSerializable` interface.

To store the arenas, we stores the object in the config file, instead of a lot of keys. The key of the object is the UUID.

Something like:

```yaml
arenas:
    '0F6607CE-3062-11E4-82D3-45C6E2E253B6': 'serialized object'
    '25C6D0A2-3062-11E4-B93B-45C6E2E253B6': 'serialized object'
```
To easily use that, we have another class, `ArenasManager`; this class provide these methods:

```java
// p = the plugin. The ArenaManager class is a Singleton.
manager = p.getArenaManager();
manager.getArena(UUID id);
manager.getArena(String name);
manager.registerArena(Arena arena);
manager.removeArena(Arena arena);

// Saves all the arenas in the config, if an Arena object is modified
manager.save();
```

The UUID is generated in the main constructor of the `Arena` class (not the "unserialize" one), used only when we needs to create an arena (else, the `ArenasManager.getArena(...)` method is used).

All the methods of the `ArenasManager` and of the `Arena` classes are public, except a few of them, to be able to provide the `ArenasManager` as an API without any change.