Separate HistoricLoad from LegacyLoad

[BenCheung0422]

This depends on #610.
It is well-known and obvious that both Save and Load, even LegacyLoad are messy and chaotic. I separate the part of version loading that is not indicated by versioning. With my investigation, world save versioning is added in 1.9.1, but save system is implemented earlier, which means there are certain versions that there are no version indicators. Then, I reorganize to check the history and to clearly write a new loading mechanism for it. Ideally, this method could be beneficial for all loading behaviour, but it is a kind of more works to do, and I do this is just for the part of #581.
A on-demand auto data fixer is included.

[Makkkkus]

I suggest not touching LegacyLoad. It works as is, and is a collection of everything using the old save feature. That is fine, and should in theory just work indefinitly (if it isn't touched). I therefore advice that this pull request should be closed.

[BenCheung0422]

There should be no big problem when the codes are not in a mess.

[BenCheung0422]

Also, can you sure it can 100% work while it is not changed? It needs to be tidied up.

[BenCheung0422]

Now when more problems fix, it is now working. Revisions for initial worlds tested: 9a09f53, 862a2e5, 585fef3

[BenCheung0422]

HistoricLoad should now be completed.

[Makkkkus]

I am still sceptical about changing this. LegacyLoad is fine as is all functions in it uses the old save format, and the current load file uses the new save format.

[BenCheung0422]

Actually no, there were bugs with the old LegacyLoad class after tests. One of them is the IndexOutOfBoundsException with the rare corrupted worlds. Also, the current design of world loading classes and methods is not really safe and can easily crash. My version performs strict tests so that corrupted would not be loaded.