feat(value): introduce Object storage abstraction

[anakrish]

First in a small series that introduces opaque storage types for Value variants so future backends can swap in without rippling through call sites. The design also lets multiple backends coexist at runtime — different Object instances in the same process can use different implementations (e.g. a lazy DB-backed object for input, inline small-map objects for SARIF location records, regular sorted maps elsewhere) and interoperate through the same opaque type.

The design and rationale are written up in docs/value/object.md. It covers the encapsulation choice, the explicit iter vs iter_sorted split, the cursor for resumable traversal, why Ord is defined against sorted iteration, and the concrete workloads driving the abstraction (SARIF small-object pressure, Kubernetes admission, Azure Policy aliases and case-insensitive compare, external/lazy data sources, eval-time arenas, host-language FFI). Precedents: serde_json::Map, toml::Table, simdjson DOM.

Layout: the new type lives at src/value/object/{mod,iter,serde}.rs; src/value.rs becomes src/value/mod.rs to make room. Re-exported as regorus::Object.

Nothing in the engine consumes Object yet — this PR is additive. Unit tests (34 covering iteration, cursor mutation-safety, ordering invariants, serde determinism with non-string keys, iterator-trait surface, etc.) stand on their own.

Follow-ups (separate PRs):

• Object migration (payload swap + call sites)
• Set foundation + migration
• Array, String, and Bindings abstractions