[tx] Optimize representation of idents and ident->entid maps

[ncalexan]

After #170, we will represent a schema as three maps: ident->entid, the inverse, and entid->schema attributes. This ticket tracks optimizing the representation of idents and ensuring the entid look-ups are fast.

There's a lot possible here, but let's start by linking to @rnewman's comments about interning idents in #32 and at #171 (comment), and his comment about sparse array maps at #171 (comment).

Generally, I think a good second iteration will be using https://github.com/servo/string-cache for idents and using a sparse map for entid lookups.

This is not a [good first bug], and it's probably not even a [good next bug].

[rnewman]

First comment, in case GitHub eats the history:

This might be worth discussing.

DB_ADD is a lazy static instance of a NamespacedKeyword. That itself owns two strings.

These cloned instances aren't immediately used and discarded, so I don't think the compiler can determine that it doesn't need to clone them.

What's the idiomatic way to avoid having to do this cloning?

I can think of:

• Using Rc to track multiple uses of a single instance of a keyword.
• Seeing if you can use Into<&NamespacedKeyword> in the signature somehow.
• Using an enum or other sentinel instead of DB_ADD directly — that is, the only allowable values here are DB_ADD and DB_RETRACT, so we don't need to represent these in Value as keywords, only as a simple enum (which the compiler will turn into 0/1). This (as with some of the other solutions) doesn't help for duplication of other keywords.
• If you can guarantee the scope in which this function and its consumers runs, you can use &NamespacedKeyword instead. The Vec<Value> could never escape the context of the parsed representation.

Second comment re entid map:

There's a better representation for this, too — a sparse array map — but that's fine to leave as a TODO!