Introduce Python wrapper for Entry, DatasetEntry, and TableEntry (#11996)

### Related

* part of RR-2901
* fixes RR-2938

### What

This PR introduces Python wrapper for `Entry`, `DatasetEntry`, and
`TableEntry`.

In more details:
- No user-facing API changes except:
  - RR-2938 is fixed
- `CatalogClient.all_entries()` is now implemented in python, and is
basically just `datasets()` + `tables()`. That means it doesn't return
blueprint dataset (if it at all did before). This aligns with the
intention to hide as much as possible the internal blueprint dataset
machinery.
- The `__repr__` of `Entry` is now more explicit with the `EntryKind`
(see snapshot diff). This comes from it now being implemented in python.
I think it's more in line with staying close too "runnable code" for
repr.
- The `DatasetEntry` <- `Entry` -> `TableEntry` hierarchy is now in pure
python.
- The previous Rust-based hierarchy is now flattened: `PyEntry` is
removed and it's functionality is integrated to now-named
`PyDatasetEntryInternal` and `PyTableEntryInternal`.
- Not having a python hierarchy on rust side simplifies/removes a whole
lot of boilerplate.
- Because it's not possible to expose a trait (e.g. `trait PyEntry`)
across the FFI using pyo3, the following is done to mitigate code
duplication:
- A new `PyEntryDetailsInternal` object is introduced, which is used to
expose the basic entry properties in `Entry`
  - An helper function for updating entries.
- At the end of the day, there remain a rust-side `Entry` informal
protocol implementation that is duplicated, but imo worth the overall
simplifications

Author: abey79

rerun_py/ARCHITECTURE.md

@@ -170,3 +170,18 @@ TODO(ab):
 - both mypy and pyright
 - tests (in `rerun_py/tests/unit/`) serve as typing test as well and should minimize use of `# noqa` and similar
 - unfortunately, PyCharm [doesn't properly support converters](https://youtrack.jetbrains.com/issue/PY-34243/attr.s-attr.ibconverter...-type-hinting-false-positive).
+
+## Internal/wrapper pattern
+
+Experience shows that the pattern of using a pure-Python wrapper around pyo3-based internal object is successful. It allows:
+- keeping the "accept anything" magic on the Python side;
+- having simple, canonically typed methods for rust-based objects (making it more likely to benefit from pyo3 magic type conversions).
+
+See `rerun.catalog.CatalogClient` for an example of this pattern.
+
+To use this pattern:
+
+- Create a Rust object named `PyMyObjectInternal` in `src`. Expose it with pyo3 as `MyObjectInternal`.
+- Crate type stubs for that object in `rerun_bindings`. These stubs should have no/minimal docstrings, since the rust-side docstrings are the reference. They should have precise type annotations, though.
+- For internal objects, prefer simple signatures, ideally with a single type per argument.
+- Create a wrapping public class `MyObject` in `rerun_sdk/rerun`. It should have a single data member called `_internal`, holding the internal object instance.