Document and test `input_shape` and `output_shape` policy

[Michael-T-McCann]

Proposed input_shape and output_shape policy:

• All instantiated Operators must have input_shape and output_shape properties
• For an Operator H, H(x) should throw an error if x is not input_shape
• Operators should be written so that H(x).shape is H.output_shape; this will not be checked and runtime, but should be tested
• Operators should attempt to automatically deduce input_shape and output_shape from other arguments and throw an error if the user requests an input_shape or output_shape that is not realizable
• The user may need to specify input_shape and/or output_shape
• The user may specify input_shape and/or output_shape when not needed to prevent them from being automatically deduced (for speed)

This policy should be described in the docs and implemented in the code.

Why this? While some operators can conceptually work with different input sizes, trying to allow this creates downstream problems, e.g., what is the adjoint of a sum operator (one that sums all the elements of a vector) applied to the scalar 1.0? How does one initialize an optimization routine without knowing input shapes for operators?