Type matcher::traversePath(Type input, ElementPath, Type constraint, bool assumeTrue);

Type matcher::narrowPath(Type input, ElementPath, Type constraint, bool assumeTrue);

PathMatchExpressions such as TypeMatchExpression use ElementPath to describe how they match on a match. 

The ElementPath has two enums:

• LeafArrayBehavior - whether we can match within leaf array like {$match: {x: 1}} will match 1 inside 'x' if 'x' is array.
• NonLeafArrayBehavior - whether we can traverse arrays if the path is dotted

This is implemented using an iterator concept parameterised by the ElementPath, which provides the matcher the elements according to these two behaviours.

We need to model the same concept in our type system, in order to be able to reason about those cases.

This ticket involves covering the most basic case needed for {$match: {x: {$type: 'number'}}} and  {$match: {x: {$not: {$type: 'number'}}}}.

Any unhandled narrowing cases just leave the input as-is.

This is LeafArrayBehavior::kTraverse without dotted path (NonLeafArrayBehavior does not matter).

This means adding the array bracket on the output, if the input is traversed (e.g. if input could be array, we could "match" a number, but since that number could be in an array, we add back array).

Something like {$match: {x: {$type: number}}} should be able to call this narrowPath({x: any}, ElementPath{x}, number, true) and the result should be number | array (array added).