feat(stack-encrypt): a declared type per field in the dynamic plan

A typed host knows what 34 is; JavaScript, PHP and Ruby do not, and index
semantics depend on it: ORE on the integer 34 and the float 34.0 differ, a
JavaScript number is a float, and match is defined over text alone. So a
plan field may now say what its values are, as `"type": "<name>"`.

The vocabulary is vitaminc's frozen leaf-tag table, one FieldType per
scalar tag, plus the two composite kinds the transport frames (array,
object); not new names. The engine uses it three times:

- building a plan refuses an unknown type name, and an index the type is
  not defined for (match on an integer, equality on a float, any index on
  a composite);
- encrypt refuses a value whose tag is not the declared type, before any
  key is minted, rather than trusting the binding's tagging, and decrypt
  refuses a field that opens to another type, so a typeless host can rely
  on the declaration for what it gets back;
- FieldType::read reads a query value as the field's type, converting a
  number only when the conversion is exact (a JavaScript 34.0 is the u64
  34 for a uint64 field).

The key is optional. A field without it is dispatched on each value's own
tag, as every field was before, so the plans existing bindings send (the
Go guest's) stay valid with no change on their side. No error variant is
added: the failures are Plan, Source and Record, which bindings already
classify as caller input.

TermKind also lowers to the typed side's IndexSpec, with the default match
options a dynamic term derives under.

Author: coderdan