Add s(w)itchable (inv)entory

[neinwhal]

This change proposes the addition of winv (s(w)itchable (inv)entory) and various other mod support for it;

• Customize your own inventory through the use of left & right sides.
• Players themselves determine the interaction they want to have, as compared to the default player inventory being the forced common perspective.
• Node inventories are supported but require manual integration; crates already does that, so you can just use crates API for simple storage nodes to apply this.

I will provide an API documentation at some point, but meanwhile, since this proposes an entirely different method of inventory handling, I just want to push it in, proceed with testing and refine the mechanisms first.

I also want to merge this in first, so I don't have two separate workflows; I consider this complete enough at the current stage and there's more essential changes to be done first - Adding new blocks and flora pieces for the spawn build / Changing and updating variations and patterns to follow the shapes format as discussed & creating a crafting station for them (with winv) such that it will be easier to locate them for the spawn build. / Adding stained glass / Working on craig-server nodes importing

Another thing is pending is accessing remote inventories (chests); This will likely be a feature pushed till much later, I'm still trying to figure out a proper way to display the data. remote.lua contains some testing code, but its by no means functional yet, because I have yet to modify crates to support it.

winv Additions / Changes:

• Move hand (item "") handling to ccore (from default)
• Move formspec prepend & inventory handling to winv (from default)
• gui_hotbar* textures are changed and moved to winv (from default)
• creative mod is deleted > handled by winv/creative.lua
• sfinv is deleted > replaced fully by winv (There's no cross support, any mods using sfinv will have to switch to winv format)
• Player's crafting grid is replaced with workbench's crafting API crafting grid.
• Add homes and a GUI that supports it
• Creative has support for various other filters including a stack size filter, and a filter by mod on top of existing ones.

ccore Additions:

• Add ccore.round, use to round a number to decimal point

crates Changes:

• Add support for winv
• Add support for overlay textures (Crates' nails and barrels' metal bands are now colored properly)
• Remove blocks' (default) chests > Handling done by crates now

workbench Changes:

• Set setting workbench_disable_crafts to true to disable workbench crafts - useful for dev purposes because workbench craft registrations take a while upon every load
• craftbench, furnace, tablesaw, cnc machine all have added support for winv (in place of that, their formspec metadata is replaced with an active on_rightclick handler; Why the change;
  • winv deals with sensitive player inventory data, unlike before where nodes just access the builtin player inventories, winv provides direct links to various other inventories.
  • And because of that, winv needs the playername for detached inventories, this means it needs direct player interaction set the inventory, making metadata inventories impossible.

Known issues

• There's no good way to update the fire animation (when to stop/start i.e), since there's no proper method to detect when the player is accessing the inventory without the usage of metadata inventories. Currently, this is done via saving the playername when rightclicking and remove it when quitting, to know if there's a need to update the fire animation, however currently it has only support for a string (1 name), so if multiple players are accessing the same inventory, it only updates the last player. This requires a slight rewrite to make it save as a table instead and handlers to check that, but its a very minor visual issue so I'm pushing it back first.
• You cannot move from output to input slots for crafting, non-related to winv but something i realized when working on it, this is due to the fact that crafting is only applied on_take (result obtained from on_take will include the moved item hence isn't viable) instead of allow_take, using the latter method would solve this issue, but is an ugly hack since I will have to make a prediction and save it for every single craft before the actual crafting - largely overcomplicated process for a minor feature. I'm still trying to think of solutions for this, but meanwhile, this is just a pending minor enhancement as well. This isn't replicable with the normal crafting because the hand itself is considered a separate slot but this is a hardcoded feature for the builtin crafting system that I am unable to use. Default furnaces don't suffer this issue as well since the crafting isn't done instantously.