Provide facilities for working with contiguous blocks of user-defined memory

## Problem

_Disclaimer:_ Problem statement is open ended and requires more consideration.

Use case:
* PyTeal developer wants to manage reads/writes to for an arbitrary number of items of state. For example, an AMM may support _n_ liquidity pools. Each pool requires managing _some_ state.
* Today, a PyTeal can use loops (among other Python constructs) to reserve `ScratchSlot`s with specific `requestedSlotIds`.
* Potential shortcomings:
* _The ergonomics can be improved._ To manage a `ScratchSlot`, the program must retain an explicit reference to a `ScratchSlot` object. It's _not_ possible to reference a slot by index alone. Consequently, some apps may be more difficult to maintain.
* _256 scratch slot limit may be prohibitive._ PyTeal compiler shares the limit (e.g. `@Subroutine` definition). Consequently, the PyTeal developer's usage may exceed the limit.

For completeness: Discussion in https://github.com/algorand/pyteal/issues/230 prompted us to more broadly consider `DynamicScratchVar` usage and write the ticket.

## Solution

We've discussed the following ideas. More homework is needed to gauge if more ideas exist and/or which one makes most appropriate tradeoffs.

| Idea | Discussion |
|-----|----|
| Define 1st class PyTeal abstractions to work with a contiguous block of `ScratchVar`s. | The idea most directly implements the request. It's possible to imagine a more generalized `DynamicScratchVar` able to index into arbitrary `ScratchSlots`. Does _not_ address the scratch slot limit constraint. |
| Provide AVM Opcodes for simplified reads/writes _within_ a `ScratchVar` and/or global storage. | Reimagines the request by broadly considering if/how the AVM can simplify reading/writing to specific byte array indices. By leveraging better ergonomics, the request _may be_ satisfied without requiring as many `ScratchVar`s. |

## Dependencies

TBD

## Urgency

Unclear