Allow primitive functions to override DSL-based default implementations

[joshsh]

Considering the proposed string manipulation functions in TinkerPop and comparing them with Hydra's current string primitives (Haskell, Java), it would be nice to close the gap, while also incorporating other useful primitives drawn from Java's String, Haskell's Data.List, etc.

The problem is that every additional primitive makes Hydra more burdensome to implement in a new language; the standard primitives are all mandatory, and you don't have a Hydra implementation until they are all implemented. A best-of-both-worlds approach might include introducing many more primitives into the language, but giving most of them default implementations using the Haskell DSL. In some cases, the operations required are too basic -- e.g. you need a multiplication primitive * to be implemented directly in the host language. Many others, though -- particularly string and list primitives -- can be reduced to programs based on lower-level primitives. Dependency tiers already provide a way of organizing primitives so as to avoid circular dependencies between primitives, their implementations, and supporting code.

So the proposal is simply to create default implementations for many primitives in the same namespace as the primitive itself -- e.g. hydra/lib/strings and move the defaulted primitives into higher tiers as necessary. This, together with a rule that, in case of collision, a primitive overrides the element of a module, would make the implementations "optional". This is similar to the way in which UDFs are expected to override module elements (#63).

[joshsh]

Note: closely related to #62. Basically, we need a sensible way of allowing primitives, UDFs, and DSL-based elements to override each other, in addition to providing default DSL-based elements for prims as proposed here.