## Description 

With the introduction of the objects_snapshot and objects_history tables, we can now support object lookups at version and latest at checkpoint, provided they fall within the available range of the graphql server. We can also get information on wrapped or deleted objects.

As such, refactor Object’s internal representation to contain a status:
ObjectKind enum with variants Live, Historical, NotIndexed, and WrappedOrDeleted,. This minimizes changes to
the current Object schema on graphql while allowing users to resolve fields of wrapped objects even if the objects themselves cannot be accessed.

The PR also implements available-range-aware single-object lookups by
constructing a union query on objects_snapshot and objects_history. We
need to look up both tables when fetching an object at version. To
illustrate, if an object was created or mutated at checkpoint 1, and the
current available range is now 100-200, a query for the object at
version 1 will not show up if we look strictly in the objects_history
table, since it only tracks object changes per checkpoint. Instead, we
also consult objects_snapshot, which will have snapshotted the object.

## Test Plan 

objects/historical.move

To fully test this feature, I also need to extend
transactional-test-runner and graphql's test infra to force
objects_snapshot table to update.

1. https://github.com/MystenLabs/sui/pull/15677 (follows this)

---
If your changes are not user-facing and not a breaking change, you can
skip the following section. Otherwise, please indicate what changed, and
then add to the Release Notes section as highlighted during the release
process.

### Type of Change (Check all that apply)

- [ ] protocol change
- [ ] user-visible impact
- [ ] breaking change for a client SDKs
- [ ] breaking change for FNs (FN binary must upgrade)
- [ ] breaking change for validators or node operators (must upgrade
binaries)
- [ ] breaking change for on-chain data layout
- [ ] necessitate either a data wipe or data migration

### Release notes