For some MLGraphBuilder methods the type of a numeric input can vary -
e.g. for constant() an explicit MLOperandDataType is provided; for
clamp() and pad() the data type is implied by input operands. In these
cases, specifying the numeric value as either a float/double or int64
type runs into accuracy or range issues - you can't accurately
represent all int64 values as a double, and you can't represent the
full range of floats as int64. (You also can't represent all int64
values as an long long either - over 2^53 things get wierd. But that's
a digression.)

Per discussion in whatwg/webidl#1388 this
change introduces a union between a bigint type and unrestricted
double called MLNumber. Callers can pass a JS number (1234, 1.1234e38)
or a JS bigint (9007199254740993n), and the implementation will treat
it properly based on the explicit or implicit MLOperandDataType. Usage
of this type should be limited to only those cases.

Fixes webmachinelearning#442

Note that webmachinelearning#492 proposes changes to the constant sequential filling
operation; this just adds IDL to match the current spec prose.

Some of the concerns raised in webmachinelearning#325 are addressed (e.g. clamp()'s
options). However, several other options are still specified as
"float", and should maybe be "double" - but MLNumber is likely not
appropriate for those, so they are not updated here.

- Introduce a "cast" definition that takes a number and a type, and returns the number cast to that type.

- Invoke cast during MLOperand and MLActivation creation.

TODO:

- Passing restrictions
  - Floating point - allow Infinities/NaNs or not?
  - Integer - throw or clamp if out of range?
- Simplify supported restrictions
- resample2d sizes option - is this part of the op data or not?

No MLActivations take MLNumber, so this paragraph doesn't make sense.
Also, add a brief intro to the cast algorithm section.

Co-authored-by: Dwayne Robinson <dwayner@microsoft.com>

Co-authored-by: Ningxin Hu <ningxin.hu@intel.com>