routing updates only trigger connected pipes

activate Visitor, finish local LSA updates, if the server has 5 networks
of 300 pipes, 1 pipe change will only update 300.
Floodfill adjacent checks and LSA updates
Change init/cleanup of routers to reduce churn
Merge remote-tracking branch 'aart/dev' into Dev

Conflicts:
	common/logisticspipes/routing/ServerRouter.java
tile can be null when it is being removed.
Cleanup.
Crafting and Provider pipes sparkle white when adding a request.
Crafting pipes sparkle purple while they have todo.
Suppliers sparkle purple while waiting for requested items.
MainProxy.proxy is client proxy in background update threads
proxy.getWorld(dim) is positively dangerous in SSP, lose it.
Just NPE if isClient/Server is called with null world
Clean up Liquid Routing.
Just in case...
Check for LSA updates every tick if multithreading is enabled
Convert most isServer calls to pass in world
Module tick() only gets called serverside from CRP, no need for isClient
Remove routerAddingDone
Clean up a few more isClient checks
supplier shouldn't reset the timer

otherwise a large request, which is delivered over several seconds
prevents the supplier ticking, potentially causing it to empty.
better thredding

added bonus: routing updates are now prioritised by the sorting function
on UpdateRouterRunnable, rather than manually on add vs addPriority

if the same router ends up in the list twice, the one with the highest
LSA is done first. a lsa version check is done first, and a set is done.
it is potentially possible that 2 threads will try to update the same
router at once, but the end result of that is just wasted cpu time, as
both threads will create the same table.
derp.
better update contention,

2 routing updates triggered at about the same time won't stomp on each
other. the later one will properly replace the earlier one, even if they
run at about the same time.
if the earlier one runs after the later one completes, then it will just
skip the update.