ConfigFile: read from SettingsReader, write to SettingsWriter

== Reading ==
Each configuration file is now instantiated with a SettingsReader. This
reader is a replacement for the old Map<String, String> settingsCache.
The setting read methods in ConfigFile have been changed to use
SettingsReader instead of the removed settingsCache.

There are currently three implementations of SettingsReader:
FileSettingsReader (reads all settings from a file, puts them into
memory), BracketSettingsReader (for the inline-settings-syntax of custom
objects, like `MyObject(Tree=true)`) and MemorySettingsReader (used to
put the settings of a network stream somewhere, can also be used in the
future for test code).

The readers have methods to "put" settings in memory. This is needed for
converting old configs, where the settings need to be converted to a new
format (like the old ReplacedBlocks syntax).

Readers can be chained: if a reader cannot find a setting, it will ask
the next reader, which will ask the next reader, and so on. This is how
biome inheritance is now implemented. See the setFallback method on
SettingsReader.

== Writing ==
Writing is now done using SettingsWriter. The only implementation is
currently FileSettingsWriter. The SettingsWriter is now passed as a
parameter to the appropriate methods. The BufferedWriter field in
ConfigFile has been removed. Previously, it was only allowed to use this
field during certain method invocations. It made much more sense to
change SettingsWriter into a parameter. Because the field no longer
exists, a lot of methods had to be removed from ConfigFile.

== Broken functionality ==
TC previously abused the low-level config file access it had. A lot of
time was spent changing these calls to something more appropriate.

The DoResourceInheritance "resource" had to go. Fortunality, this
resource was undocumented, so I doubt many people relied on this. A
boolean setting will take its place. (Not Yet Implemented)

BO2s were also difficult to fix. Dropping BO2 support is no option, so
the design of SettingsReader had to be compromised a little bit. A
getRawSettings method had to be added. An appropriate warning has been
placed in the JavaDocs.

== Future plans ==
* The default settings of biome configs (StandardBiomeConfigs) can be
changed to use the SettingsReader. The BiomeConfig class will then no
longer have an idea what settings are overridden by the specific biome.
* The WorldSettings class is somewhat problematic. The name is too
generic, and it couples the LocalWorld to the file system to the
configuration system.
* FileSettingsReader knows exactly which settings are in the file, so
maybe FileSettingsWriter can use this for biome inheritance? We could
then finally enable config writing for biomes using biome inheritance.
We would then only write the settings that were actually read. We can
also go for a different approach, where only the settings that are
actually different from the parent biome are written to the file.
Rework config functions a bit

- Inheriting now works properly, there is a new setting called
ResourceInheritance in each BiomeConfig.
- Added line numbers to most error messages.
- Moved isAnalogous up to the ConfigFunction interface, so that
SettingsReader doesn't need to know about Resource.
- Added a default implementation of isAnalogous to Resource, removed all
overriding methods that used to do the same thing.
- Corrected some usages of deprecated ConfigFile.name and file fields.
Fix TC not throwing an error when encountering invalid materials

Also fixed some typos in nearby code.
Fixed error creating files when parent directories do not exist yet
Update MCPC+ detection to detect Cauldron instead