Triple, Node and URI expansion for TriplesGraph

This addresses #12 . However, don't be so willing accept this pull request yet @robstewart57 :-)
It introduces some inconsistency that I would like to highlight below and discuss.

First and foremost, `select` and `query` functions of `TriplesGraph` did not work as announced by the original author - they called `expandTriples` function, which was supposed to expand triples' namespaces and filter out duplicates. However it was not implemented and it just returned triples intact. I implemented the body of that function and also added `uniqTriplesOf` (better name pending) function as a companion of `triplesOf`, which returns unique and expanded triples unlike the latter. Now `select`, `query`, `isIsomorphic` and other query functions should work properly.

But we now deal with the following inconsistency: `triplesOf` returns non-expanded triples, `select` and `query` return expanded triples. Perhaps this could lead to confusion when you suddenly get triples that you "never added to the graph". At least, not in the format that they were added. All other functions that use `triplesOf` behind the curtain are going to produce a bit different output than that of `select` and `query`.

And now I'm looking at `MGraph`. It appears that `MGraph` needs that expansion routine implemented too, but due to the graph nature, it must have that expansion performed when triples are added to the graph. Since `MGraph` is a map tree, it effectively "avoids" duplicates, but node expansion is a must, because expanded and non-expanded nodes will compose different branches.

All that brings up a question whether `TriplesGraph` really needs that expansion and duplicate filtering of triples. We have 2 different types of RDF graphs, each having a distinctive set of pros and cons, so perhaps having duplicates and naïve "handling" of namespaces is a "feature" of `TriplesGraph`? On the other hand, not handling namespaced URIs is just too cruel. I could bear having duplicates in `TriplesGraph` at the cost of... graph building speed? While `MGraph` takes longer to build, but is (arguably) better for querying and has no duplicates. Perhaps there is a third or a fourth option too, and we could explore other kind of graphs, or even limit RDF4H to just one?

So my point is: introduction of namespace expansion and handling of duplicates is actually much bigger than issue #12 . It is perhaps quite a dramatic change for the project and it must permeate it wholly and systematically. And we must definitely bring namespace expansion to `MGraph`.

In the light of the abovementioned things, this pull request is not "complete". You can accept it as work-in-progress, but it's certainly not ready for a release.