Redesigned texture state system

It started as my quest to expose BC Facades API, but I was stuck while messing with rendering so I decided to experiment with it and I made such improvements and I present them for code review:

1)Pipes are now ICullable(May need a bit work to represent all the culling functionality from pipe blocks[If this gets accepted create issue "Complete ICullable API" please])
2)Pipes are now have their texture state machine in Block instead of TileEntity Client State. This may reduce memory footprint if I am correct.
3)Due to this vanilla block renderer now can access texture state using getIcon(int, int) instead of using one with WorldAccess to look for TileEntity to get its Client State. So it should be MUCH faster.
4)Texture State object has its own texture array minipool(for one object) which can be switched on and off using popArray()\pushArray() to avoid IIcon[6] allocation for each pass from Facade Renderer.
5)Pluggables now use Fake Block as their state manager for culling and texturing. This will help me to expose pluggable api without enforcing end-users to make their blocks depend on ICullable and ITextureStates from BC.
Up until now, each time we had to implement a singleton, we did it directly as a static final field of the class itself - that is, just moving INSTANCE in FakeBlock directly. I'm not aware of any safety vulnerability by doing so. With regards to the on-demand aspect, I suppose that the initialization of INSTANCE is not called before the class FakeBlockHolder is initialized - is that correct?

I would prefer to stick to the usual scheme here and put the field directly in the FakeBlock class. Systematic initialization shouldn't be an issue here.

Did I understand things correctly?