Rewrite/overloadmap as tree

[jitsedesmet]

This pull request aims to provide a first implementation for transforming the overloadmap to a tree structure. This removes it dependency on the 'immutable' package and should allow us to auto cast some concrete types.
In the first version of this PR I added 3 TODO's. These should not be merged into master but should be discussed here and resolved before merging.

[coveralls]

Pull Request Test Coverage Report for Build 1116703798

• 51 of 54 (94.44%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.04%) to 88.294%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
lib/functions/Helpers.ts	16	19	84.21%

Totals
Change from base Build 1112636241:	0.04%
Covered Lines:	1298
Relevant Lines:	1430

---

💛 - Coveralls

[rubensworks]

I've added some comments, but I don't fully understand what the code does; likely due to the minimal documentation.

[rubensworks]

Looks much clearer now :-)

Let's wait for @wschella's feedback, as this change is pretty invasive.

[wschella]

I'll talk about both TODOs here.

What this function does is copy the implementation from one overload (i.e. a list of types) to another. So basically it makes two overloads behave identical. What this loop (and the equals) does is iterate over the list of existing (types, implementation) pairs (i.e. overloads) and when it finds a match with _from, it copies that implementation and it's a new overload with this implementation and the types as defined in the to argument.

So the arraysEqual is necessary if we want to keep logic like this. This is okay as it's done only once. This Builder class is simply the 'DSL' I talked about: it's a way to create overloaded function definitions for our SPARQL functions with the Builder pattern. It's all static info.

Now, you don't necessarily need to keep this logic. If instead of keeping a a list of implementations (this.implementations), you just build the OverloadNode directly, you could maybe use the search method here, although it would have to a searchExact, we only want exact type matches for this function. This will clean things up, but it would require rewriting most of the Builder functions (e.g. onUnary) to operate on the tree instead of the list. This should not be too difficult.

The copy (the first todo) is not necessary, with the same reasons as the one in the .set function.

[jitsedesmet]

I'll leave rewriting this file for another time. I removed the TODO's :) Thank you!