Add `NetworkTransform` to an object and move it. The client that owns it sends, every other client
plays the motion back, and a still object costs nothing.

## Why not continuous sync

Udon's own continuous sync replicates on a timer whether or not the object moved, and smooths with
a curve nobody chose. `NetworkTransform` sends only when a channel has actually changed by more
than its threshold, and does its own interpolation, so a stationary object is one comparison a
frame rather than a packet.

## The settings

| | |
|---|---|
| `SyncPosition`, `SyncRotation`, `SyncScale` | Which channels travel at all |
| `SendRate` | Sends per second while something is moving |
| `MinPositionChange`, `MinRotationChange`, `MinScaleChange` | How much a channel must change to be worth sending |
| `ResendInterval` | A heartbeat that heals a dropped update |
| `TeleportDistance` | Past this, a jump is played as a jump rather than interpolated |

`LastSentBytes` and `DroppedSends` are readable at run time when you want to know what a moving
object is actually costing.

## What it does with a pickup

With a `VRC_Pickup` on the same object, picking it up takes ownership, so the person holding it is
the one sending. Dropping it sends the resting pose. Nothing extra to wire.

## What to expect

**Playback runs one send behind.** Each arriving snapshot is played from the previous one over the
gap between them, which gives constant-velocity motion instead of the pulse-and-decelerate of
easing toward a target that jumps ten times a second. The price is one send interval of lag on top
of the network's own.

**A late joiner sees an untouched object correctly with no packets at all,** because the scene
already carried its position. A client that has never received a snapshot leaves the transform
exactly as it was serialized.

**Only the owner writes.** A client that owns the object never interpolates its own movement, so
what you feel while holding something is your own motion rather than a replayed copy of it.