Vector docs should specify whether parameter order and inclusion is required

[ahouseholder]

Breaking this out from #88 to make it separately decidable

The docs should specify whether order of parameters matters and how to determine that (is there a canonical ordering?) My own opinion is that order shouldn't matter.

Closely related is whether all keys are required for the vector or if some may be omitted when information is only partially specified.

Questions that should answer:

• Must vectors always keep key:value pairs in the same order?
• How to handle unspecified elements? This is the omit/include-but-indicate-unknown item. E.g., what if I don't know the answer to Exploitation but I have answers to the others?
• How to handle underspecified elements? E.g., what if I know Exploitation is not PoC but I don't know if it's none or active? Can I use the vector indicate what I do know?

[ahouseholder]

Copying out comments from #106 since this issue intersects these items.

• in the vector notation, address underspecification as well: E.g., E:[N,P] for the previous example.
• in the vector notation, consider a wildcard character in place of a full list when a decision is entirely unspecified e.g., X:* instead of X:[A,B,C,D] if X has four options, but X:[A,B] if we know X is neither C nor D.

[j---]

Will clarify that the purpose of the vector is to communicate known information about whatever decision points there is information for.
decision points with no information should just be omitted from the vector.
Order cannot be tied to a tree, because tree is not tied to the vector.
There should be at least one decision point with some information about it in the vector.
The purpose of the vector is not to replace the JSON, so the JSON will have features not in the vector. The vector is a function of the JSON, but there is no plan to support creating a JSON object from a vector. We don't plan to support a regex or other method to validate vector syntax. Schema will not include the vector as an entry.