Sector cache management

This is essentially a replacement for #2604 with the commit history cleaned up a bit for easier review **plus** the last finishing discussed there.

As you see from the commits, the great groundwork has been done by @fluffyfreak with me climbing on this shoulders afterwards ;) So, a big thank you for that.

1. The code has been rebased to current ```master``` and the now unneeded merges removed
2. The minor changes (unused variables and headers) have been merged into the respective commit

And nor for the **news**:

3. The ```SectorCache``` has been split into master and slave caches
  - The master tracks naked (non-refcounted) pointers to the ```Sectors``` and is only responsible for ensuring that we always have at most one ```Sector``` object for each sector (i.e. that sector objects are unique). The master cache **does not** keep ```Sector``` objects alive, it only tracks the objects others are interested in.
  - The master can be asked to create slave caches that keep ```RefCountedPtr<Sector>```, so a slave cache is what can keep the objects alive (of course you can also keep sectors alive without a slave cache, e.g. the ```Factions``` keep alive their home sectors without using a slave cache). The slaves can be filled by the threaded ```SectorCacheJobs```. Those only get a list (vector) of ```SystemPaths``` to be determined by the user of the slave cache. That way, the logic, what is to be cached is back in the specialized modules
  - There are currently two slave caches
    1. One in ```SectorView``` (yes, it's back where the sector cache began ;)), which is filled by local ```GetCached``` calls and reduced by ```SectorView::ShrinkCache```. 
    2. The second one in the ```Space``` object and filled from ```Space::GenSectorCache```. Since the lifetime of a ```Space``` is limited to the next hyperjump, there is no need to provide a way for shrinking the cache. But since the new ```Space``` is created when the old ```Space``` is still living, only sectors that weren't tracked by the previous incarnation need to be generated. The others will retrieved from the master cache (still kept alive by the previous ```Space```). A small addition was needed to provide the hyperspace ```Space``` with the destination of the jump, so that the chain does not break.
4. The last places in factions code that required creating their own ```Sectors``` could now be switched to the cache. However, that stuff is a bit hairy: When called from certain places in the factions code, we must not assign factions to the sectors, either because factions are not yet fully generated, or because we would otherwise create an endless ```AssignFactions``` recursion (when factions retrieve their home sectors).
5. I have added some places, where caches are cleared, e.g. after generating factions and on starting and ending games. This is partly in preparation for a time, when sectors can be changed in-game and partly because of factions now using the cache in initialization code.

@fluffyfreak: From my point of view it's ready for merge. Could you give it a review, please?