First step towards a new settings system

Summary
=======
Got rid of the settings enum, and replaced it by contants. This allows
for type safety. Settings are now responsible for reading and writing
their values, instead of tons of overloaded methods in ConfigFile. Added
a few tests.

The Setting class
=================
Each setting type now extends Setting<T>. The type parameter T is the
type of the value of the setting, like String, Integer, Boolean,
List<String> or even SurfaceGenerator. Each setting implements the
methods "T read(String)" and "String write(T)". There's also a method
called "T getDefaultValue()".

ConfigFile changes
==================
There are now two method left that read settings: "<T> T
readSettings(Setting<T> setting)" and another one that allows to
override the default value from Setting.getDefaultValue: "<T> T
readSettings(Settings<T> setting, T defaultValue)". This is used by
BiomeConfigs.

There is only one method left that writes settings: "<T> void
writeValue(Setting<T> setting, T value)". It simply calls the write
method on the setting, and writes the result to a file.

The Settings factory class
==========================
"Settings" acts as a factory for creating settings. WorldStandardValues,
BiomeStandardValues, etc. now extend this class, instead of implementing
MultiTypedSetting, that has been removed. The classes are no longer an
enum. Enums force all values to have the same type. Now the settings
type are much more explicit.

The reason for creating factory methods instead of calling the
constructor is that we may want to keep track of all settings in the
future. The old settings enum provided this functionality, and the
factory methods allow us to do so too.

Variable names
==============
Constants are now UPPERCASE_LIKE_THIS, variables are now camelCase. In
the settings file you will still see SettingsLikeThis. This can be done
now that variable names and setting names have been split. Value enums
(like TerrainMode) haven't been split yet, so they keep their variable
names LikeThis for now.

Next steps
==========
- Move the file reading/writing logic out of ConfigFile, so that
settings can be read from different sources, like Mojang's new settings
format used in the Customized world type.
(http://minecraft.gamepedia.com/Customized)
- Remove all unused settings. This includes all structure settings of
BO2 (support removed in TC 2.3, replaced with BO3 structures in TC 2.4)
and the two color settings from the WorldConfig (support removed in TC
2.2, now handled by biomes)
Use spaces is most lists

"a,b" --> "a, b".

Some time ago Setting:Value was changed to Setting: Value, and now lists
are using extra space too.

Resources aren't yet using spaces, as they would require changes in a
ton of places. It will happen eventually, but it's not a prority.
Use HTML notation for writing colors

The "0xffffff" isn't common as a color syntax, "#ffffff" is much more
common. Colors are now also written in uppercase.
Merge branch 'newSettingsSystem'