created a power api, and protected against recursive requests.

also removed IPowerRouter, as that was an interface nothing used, or was
ever able to, as the use of actual routers was embeded too deeply, and
its not possible to have a router which doesn't know about power.

main changes are the boolean useEnergy(int amount, List<Object>
providersToIgnore) , which in which powerProviders should check that
they are not on the list before passing on.
Pipes do not add themselves to the list, to make normal operation with
no recursion a simple null-check; they expect all ILogisticsRouters,
which they unconditionally defer to, to do the inclusion check)
The logistics power junction does not need to add themselves to the list
either, as they never recurse.

net effect: no extra cpu load for LP, other networks can add power
sources, and potentially be powered by LP without worying about
recursion effects.
Convert _lastLSAVersion and SharedLSADatabase to arrays.
Use explicit new/copy/replace to prevent unguarded accesses from seeing invalid state.
Merge the 3 cleanup-on-shutdown static methods
catch an error condition without crashing.
Provider modules do not over-stuff crafters

according to (where base is an adapted special inventory, if needed)
IInventoryUtil inv
=SimpleServiceLocator.inventoryUtilFactory.getInventoryUtil(base);
+   count += inv.roomForItem(item, 9999);
missed a file in previous commit.
the new crafting module shouldn't override the gui of the pipe.
provider pipes and satellite pipes don't over-stuff
round up, so that you don't under-commit.
some modules do not want passive routed items

old passive code paths ignore the new modules.
a step towards active routing modules.
fix a NPE when a pipe unloads with an item heading towards it.

this code assumes that arriving at the next pipe will re-route it; the
sending of an item to a pipe that doesn't currently exist needs to be
detected earlier.
chassi modules can be null

why didn't this npe on me during testing?!
normal recipies only have 1 item per slot.

pre-loaded act's can have stacks of items, this will only import 1 from
each of them.
and a null check
avoid excessive re-requesting ...

when crafters with full inventories and no TODO bounce items, they won't
re-request them.
skip crafters with high load

at the same priority, don't add to crafters which have a large load.

eg: you request 200 items, and a crafters have 500, 200, 200 todo, it
will skip the 500.

(criteria is skip crafters with todo of < min(load)+request/2 ; if that
fails, use crafters with todo< min(load) +request.
and the interface update.
Add transactor functionality to specialinventoryhandlers
defensive null check
remove, not skip when todo = 0 and full.
continue;