before anyone starts screaming:
1) it's easy to create your own wrapper that converts items to arrays
2) there is no longer a single standard way to encode items.
3) the way that item serialization now works requires an ItemSerializer, which, barring singleton use, must be dependency-injected. Since there's no way to inject dependencies into jsonSerialize(), this means that its behaviour cannot be customized.
this should hopefully be more attention grabbing and a bit less misleading, since people will wonder why there are 'remove' and 'removeItem' both.
we really need to rename one of these...
avoid the overhead incurred by clear() and setItem(), because in internalSetContents(), we already have no listeners or viewers to talk to anyway, so this is just spamming shit into /dev/null.
we don't usually add VanillaItems entries for blocks since they already exist in VanillaBlocks, but air has a special use case specifically as an itemstack, so we make an exception for this case.
I moved these to a trait in anticipation of having multiple full Inventory implementations. That's no longer necessary because of the abstraction of SimpleInventory.
previously, these were forced to extend BaseInventory because of the amount of crap in Inventory's interface.
This meant that these inventories had their own slots storage, which would be _mostly_ unused because these inventories aren't real inventories, but rather just delegates.
This lead to a variety of bugs in the past, such as certain API methods on BaseInventory not working correctly for DoubleChestInventory in particular.
Now, BaseInventory just implements the functional part of the inventory implementation, leaving the storage system up to the implementation.
A SimpleInventory class is provided with a simple SplFixedArray storage backing, which is used by most inventories.
EnderChestInventory and DoubleChestInventory now extend BaseInventory directly, and implement custom methods for dealing with their delegates.
now, EnderChestInventory is just a temporary window, much like anvil/enchanting windows. It provides a gateway to the player's PlayerEnderInventory.
This removes one of the remaining obstacles to disallowing null World in Position constructor.