Allow remapping blockstates and block properties via addons

[TBlueF]

This PR is an alternative implementation of #754

[TBlueF]

@Doridian Hi, this would be my suggestion for implementing the resource-mapping. I moved the mapping out of the ResourcePools because it doesn't make sense for most resources to have this kind of mapping and creates further issues/confusion down the line in my opinion.
Only for the mapping from BlockState-Id to the BlockState resource-file it makes sense.
Also e.g. adding additional Textures during rendering (instead of on load time) breaks bluemap's TextureGallery (-> the class keeping track of textures <-> texture-id's for each map). So we don't want to make that possible.

The only thing i am still unsure about is, i don't really like looping over all pack-extensions each time #getBlockState() is called, since that happens at least once for every block that is being rendered which can be quite often and if an addon isn't careful and does something slow here then this could slow down rendering by a ton..
But i don't really see a better solution for that at the moment..

What are your thought about this implementation? :)

[Doridian]

But i don't really see a better solution for that at the moment..

Yeah, we have to rely on addons not being silly with what they do in these calls. And also a cache should be possible here for Key -> Key maps, as those changing makes little sense, so once a single key has been mapped, it can be assumed that such mapping is "stable". And could be stored in a Map or a cache of some sort.

What are your thought about this implementation? :)

The only possible downside I can see: If an addon uses .getBlockStates().get(...), it will now receive the "raw" mapping, without remapping.

But yeah, LGTM