Smarter coordinate plane

@alphalambda I'm creating this issue to capture thoughts about the coordinate plane.

Trying to sum up the current state of things: the built-in `coordinatePlane` picture extends from -10 to 10 in each direction. It is useful when it's added as-is with no transformations. However, attempting to scale it, translate it, etc. doesn't work so great, because (a) it's a fixed size, (b) the granularity of guidelines is fixed, and (c) the labels don't stay readable if you stretch them, especially non-uniformly. It would be great for a lot of educational purposes if one could instead get a coordinate plane of any dimension, and trust it to look right (the right bounds, readable labels, and a reasonable choice of guides).

The rest of this document is brainstorming how to make this work.

### Option 0

Do nothing. CodeWorld doesn't need to solve all problems, and sometimes the complexity cost of adding a solution outweighs the benefit.

### Option 1

Create a new function that draws a coordinate plane with specific parameters. Looks like this could be an internal size (range of values in x and y that can be represented on the plane), and maybe also external size (amount of screen space to draw it in).

### Option 2

Make the `coordinatePlane` picture "smart", so it reacts to being transformed. It would be somewhat unique among pictures, both in that it's infinite in size (of course, the implementation would be to just draw the visible part), and would actually adjust the picture when it's transformed, so that for instance if it's scaled down, the granularity of the guidelines would change, and the labels would be drawn at the correct place, but without other transformations.

I don't think there's anything wrong with an infinite picture. None of the built-in pictures are infinite, but one could imagine changing that in some future world. It makes semantic sense. (Some students already complain about having to choose some arbitrarily large size to make a background for their programs, and would like a `everywhere :: Picture` that's infinite and solid, so they could write `background = colored(everywhere, blue)`. I'm not proposing to add this, but it's not unreasonable.

The latter difference, though, definitely breaks the denotational semantics of the `Picture` type as `Point -> Color` (see #456) which I don't like if it's avoidable. Then again, `coordinatePlane` is kind of a debugging feature anyway, and debugging often breaks abstractions.

### Option 3

(just brainstorming here; I don't really like this one.)

Deprecate `coordinatePlane` as a picture entirely. Instead, add a debug control to draw a coordinatePlane that can be toggled at runtime. In conjunction with #938, students could get more flexibility in the abstract size of their canvas, and that may satisfy many of the use cases for coordinate planes. On the other hand, it's bad for students who might want to use a coordinate plane as *part* of a bigger animation or drawing. Here's an example of that: https://code.world/#PrjRYVwRnctivph7EKKInwg I could never have made that animation had `coordinatePlane` been a toggle button in the UI instead of part of the code.

This is a brainstorming issue and names no implementation files or tests. Start by reviewing the current coordinatePlane behavior, then read the linked discussions in #456 and #938 and compare the proposed options. Done is not defined because the issue does not select an approach or specify an acceptance criterion.

Vom Indexierungsmodell aus dem Issue-Text verfasst.