_Commits make no sense, review the final changelog directly._

_All the interesting bits happen in `re_log_types/time_point` & `re_sdk`
-- everything else is just change propagation._


- `TimeInt` now ranges from `i64:MIN + 1` to `i64::MAX`.
- `TimeInt::STATIC`, which takes the place of the now illegal
`TimeInt(i64::MIN)`, is now _the only way_ of identifying static data.
- It is impossible to create `TimeInt::STATIC` inadvertently -- users of
the SDK cannot set the clock to that value.
- Similarly, it is impossible to create a `TimeRange`, a `TimePoint`, a
`LatestAtQuery` or a `RangeQuery` that includes `TimeInt::STATIC`.
If static data exists, that's what will be returned, unconditionally --
there's no such thing as querying for it explicitely.
- `TimePoint::timeless` is gone -- we already have `TimePoint::default`
that we use all over the place, we don't need two ways of doing the same
thing.

There still exists a logical mapping between an empty `TimePoint` and
static data, as that is how one represents static data on the wire --
terminology wise: "a timeless timepoint results in static data".

Similar to the "ensure `RowId`s are unique" refactor from back when,
this seemingly tiny change on the surface will vastly simplify
downstream code that finally has some invariants to rely on.

- Fixes #4832
- Related to #5264


---

Part of a PR series that removes the concept of timeless data in favor
of the much simpler concept of static data:
- #5534
- #5535
- #5536
- #5537
- #5540

Introduces the concept of static data into the data APIs.

Static data is a on a per-entity per-component basis. If it exists, it
unconditionally shadows any temporal data of the same type. It is never
garbage collected.
When static data is returned, it is indicated via `TimeInt::STATIC`.

The terminology has been normalized all over the place: data is either
static or temporal, and nothing else.

Static data cannot have more than one cell per-entity per-component.
Trying to write more than one cells will trigger last-write-wins
semantics, as defined by `RowId` ordering.

Timeless fallbacks just don't exist anymore, which simplifies out _a
lot_ of code in the datastore and query cache.

Note: static data is in many subtle ways incompatible with our legacy
InstanceKey-based model, which results in a couple hacks in this PR.
Those hacks will be gone as soon as the new data APIs land and instance
keys go away.

- Fixes #5264
- Fixes #2074
- Fixes #5447
- Fixes #1766


---

Part of a PR series that removes the concept of timeless data in favor
of the much simpler concept of static data:
- #5534
- #5535
- #5536
- #5537
- #5540

Just exposing all the new static stuff to the Python SDK, and trying to
kill the "timeless" terminology in the process.

---

Part of a PR series that removes the concept of timeless data in favor
of the much simpler concept of static data:
- #5534
- #5535
- #5536
- #5537
- #5540

Just exposing all the new static stuff to the C & C++ SDKs, and trying
to kill the "timeless" terminology in the process.

---

Part of a PR series that removes the concept of timeless data in favor
of the much simpler concept of static data:
- #5534
- #5535
- #5536
- #5537
- #5540