Refactor IDMapping Manager

[sgratzl]

ideas:

• mappings don't need to be mutable -> immutable can faster + threadsafe + less wasted memory
• lazy #955
• there is no need for a mapping graph per id category, one graph with multiple components will fulfill the same purpose
• object mappings, e.g. david -> GLPathway, all just one mapping
• functional mappings, e.g. PathwayVertex -> ID : id is stored in PathwayVertex no need to store it to be able to map it
• use advanced optimized data structures: BiMaps, MultiSets,...
• lazy routing: as routing is a very expensive operation, a lazy variant should look for the route, when it is needed the first time

[alexsb]

What would be the benefit of this? That you just have one static IDMappingManager?

that is is one benefit. In addition you need the graph management only once, which may save additional memory.

What do you mean with functional mapping?

Assume we allow complex object (e.g. unique objects, pathways) stored within the mapping graph.

Mapping a pathway object to its id can be done without a lookup table, as the id is stored within the pathway object. So you can define a function that maps pathway object to its id and saving the memory.

Similar thing vor pathway vertices and pathway vertex reps. Both already store the mapping in the object. So you don't need to store that mapping again.