…utation``:

- The current implementation of the computation classes (and the base computation class) will become stale when EOF is introduced because it always assumes a "message" which has transaction fields. We should refactor the actual base computation class to have only the inherent properties of base computations.

- The ``MessageComputation`` class then inherits from a simpler, stripped-down ``BaseComputation`` class. Existing VM computation classes are now ``MessageComputation`` classes since they inherently require a ``message`` and ``transaction_context`` starting at the ``__init__()`` method and stretching across some of its methods and properties.

- This hierarchy paves the way for EOF computations, and possibly other computations, to exist within a more flexible model. EOF computations are likely to be properties of message computations since an EOF computation cannot be executed without a message / transaction.

- Define computation children in the ``BaseComputation`` class and narrow the type as needed for subclasses - e.g. for ``MessageComputation`` narrow the children to be ``MessageComputationAPI``.
- Some minor cleanup along the way.
- Add newsfragment