Implement multifaceted virtual objects

[FUDCo]

These changes implement the multifaceted virtual objects API per our current design.

Closes #3834

[FUDCo]

Probably worth calling out for the record one small change to the code as implemented from the implementation design in #3834: this implementation uses a different separator character (in this case, comma) between the main portion of the vref and the facet identifier than the separator character (slash) between the base kind vref and the instance identifier. The design proposed the new multi-facet virtual objects would get o+NN/AA/BB, where NN is the kind ID, AA is the instance (cohort) ID, and BB is the facet ID. I found it highly advantageous to use o+NN/AA,BB instead, as there are numerous cases where I needed to strip off the facetID while leaving the rest intact, and having a separate separator meant not having to count separators. While I don't think this bit of minor pragmatism is likely to be terribly controversial, it warrants mention.

[erights]

I reviewed what I understood. But even after it looks good to me, you should get @warner's approval before merging. There too much I simply cannot evaluate.

[warner]

I'm submitting a partial review to start the discussion, I'll re-request myself for review and continue the process tomorrow. I've only gotten as far as virtualReferences.js.

[warner]

Should we mention (maybe with a TODO) that this set might vary between instances? Or that init() "SHOULD" return the same set of properties for all instances, even though maybe we don't catch this yet, and that a future implementation will be strict about enforcing it?

[FUDCo]

I think we need to make a decision whether we are even going to allow init functions to return different object shapes within a kind.

[warner]

Right, but I think we have opinions (we're in favor of fixed-shape, because give us more flexibility to make a real DB schema, right?), so we should make it clear that authors ought to use a fixed shape, even if we aren't enforcing it yet. "All instances of a given kind ought to have the same set of properties" might be enough.

[erights]

Hi @FUDCo I asked myself for another review. Please don't squash any further changes yet.

[warner]

• cohort record needs retention
• type naming comments

[warner]

Right, but I think we have opinions (we're in favor of fixed-shape, because give us more flexibility to make a real DB schema, right?), so we should make it clear that authors ought to use a fixed shape, even if we aren't enforcing it yet. "All instances of a given kind ought to have the same set of properties" might be enough.

[warner]

ceaseRecognition needs discussion, the rest is minor, we can land once we figure out that one.

[warner]

My remaining requested changes are cosmetic: comments and assert description strings. Feel free to land after you've added those (and rebased/squashed/etc).

@erights said he was satisfied but his review says "Changes requested", so I'm going to dismiss his review so it won't prevent you from landing this (and so we don't have to bother him with a re-review request).

@erights said he was satisified in the comment