Make operand data type and rank validation table-driven

[inexorabletash]

Improve readability of input operand data type and rank by introducing a table within each method definition that lines the restrictions for positional arguments and options. Steps are updated to reference the table columns.

---

Preview | Diff

[zolkis]

I'd prefer this style than the one in #646

[inexorabletash]

A few questions to consider:

dataType

• For most "secondary" operands, the type is constrained to be the same as the primary operand. The relevant steps could be written as either:
  • "If mean’s dataType is not one of its allowed data types, then throw a TypeError." - more consistent.
  • "If mean’s dataType is not the same as input's dataType, then throw a TypeError." - clearer.

rank

• In most cases there's only one allowed rank. So do we prefer:
  • "If mean’s rank is not its allowed rank, then throw a TypeError." - more consistent.
  • "If mean’s rank is not 1, then throw a TypeError." - clearer.
• If we prefer the former (reference the table), what about Simplify, correct, and add validation for GRU/LSTM and friends #659 which proposes simplifying some validation e.g. "If mean’s shape is not equal to « input’s shape[options.axis] »..." — this implicitly validates the rank. If we had that, would we still want a step reading "If mean’s rank is not ..." ?
• If any rank is allowed, do we still want to include the step, for consistency?

General

• Should we add a "validate the dataType and rank of an operand" helper algorithm? The steps for each operands could then be collapsed to just: "If validating the dataType and rank of mean returns false, then throw a TypeError." - less text, but more is hidden behind the algorithm.
• When there are multiple input operands, do we prefer separate steps or combined steps? At an extreme we could even write: "If validating the dataType and rank of any of mean, variance, options.scale (if it exists) or options.bias (if it exists) returns false, then throw a TypeError."

[zolkis]

IMHO the "consistent" option is clear enough in this case. :)

[inexorabletash]

Other notes:

• For the op groups (element-wise binary/unary/logical, pooling, reduction) a table is not given and the inline steps are retained. Any better suggestions?
• Do we keep a rank validation step if there's a subsequent shape validation step? i.e. keep both of these lines:
  1. If mean’s rank is not its allowed rank, then throw a TypeError.
  2. If mean’s shape is not equal to « input’s shape[options.axis] », then throw a TypeError.

[zolkis]

For the op groups (element-wise binary/unary/logical, pooling, reduction) a table is not given and the inline steps are retained.

Looking at the preview, I think that makes sense.

Do we keep a rank validation step if there's a subsequent shape validation step?

Shape should include rank... I'd leave rank out and let impl optionally handle that as a quick check, if it makes sense somewhere.