Document and test `input_shape` and `output_shape` policy

Proposed `input_shape` and `output_shape` policy:
* All instantiated `Operator`s must have `input_shape` and `output_shape` properties
* For an `Operator` `H`, `H(x)` should throw an error if `x` is not `input_shape`
* `Operator`s should be written so that `H(x).shape` is `H.output_shape`; this will not be checked and runtime, but should be tested
* `Operator`s 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?

No files or tests are named. Start by locating the Operator base class, shape handling, and existing operator tests and documentation, then map which implementations need the policy. Done means the policy is documented, implemented consistently, and covered by tests for shape deduction, validation, and output shape.

Written by the indexing model from the issue text.