avm2: Address feedback to DropShadowFilter stub

render: Don't use BitmapHandle in tessellator

Currently, we rely on ShapeTessellator being able to get a BitmapHandle
without a RenderBackend. With the upcoming BitmapData refactor,
we will always need a RenderBackend to get a BitmapHandle, which creates
borrow-checker issues in ShapeTessellator (which is stored in a
RenderBackend).

To solve this, we split BitmapSource.bitmap into two methods -
BitmapSource.bitmap and BitmapSource.bitmap_handle. ShapeTessellator
continues to use BitmapSource.bitmap, and uses the u16 bitmap id
instead of a BitmapHandle. The BitmapSource.bitmap_handle method
is used inside each render backend to convert the id to a BitmapHandle,
avoiding borrow-checker issues.

avm2: Refactor context menu field bool checks into macro

avm2: Add missing set_object2 impl to Bitmap

avm2: Remove `From<Box<dyn std::error::Error>> for Error<'gc>`

render: Treat `update_texture` with invalid `BitmapHandle` as an error

This should be impossible to trigger from ActionScript, so
we shouldn't ignore it.

avm2: Implement some of SharedObject

Our AVM2 `SharedObject` support is now *almost* equivalent
to our avm1 `SharedObject` support. We implement serialization
and deserialization for primitives, arrays, and `Object` instances
with local properties. We also implement serialization for `Date`,
but not `Xml` (since our AVM2 `Xml` class is just a stub at the moment).

This is enough to make 'This is the only level too' save level
progress to disk.

Currently, we always serialize to AMF3. When we implement
the `defaultObjectEncoding` and `objectEncoding`, we'll need
to adjust this.

avm2: Remove `GcCell` from `local_registers`

We already have `&mut self` available whenever we write to it,
and we never made use of the `Clone` impl. As far as I can tell,
we don't have any unimplemented features that would require a `GcCell`.

avm2: Declare 'dataFormat' property on URLLoader

This ensures that a sealed subclass can still access it.

core: Correctly calculate the length passed to `resize_to_reader`

In several places, we read some data from a tag, and then pass
the original tag length to `resize_to_reader`. This is incorrect -
the provided length is used an an offset from the current position
in the reader, so we will extend past the end of the current tag if
we've already read some bytes.

In practice, this doesn't appear to cause any problems - AVM bytecode
has internal length fields, which end up ensuring that we will never
try to read past where the slice *should* end. However, if a `DoAbc`
tag is the last tag in the file, then we'll end up trying to use
`resize_to_reader` with an offset past the end of the movie.

This commit subtracts the number of already-read bytes from `tag_len`,
to ensure that we always construct a correctly-sized `SwfSlice`