Allow clients to specify `now` timestamp for `<type> with expiration`

[dystopiandev]

Problem Statement

Per https://authzed.com/docs/spicedb/concepts/expiring-relationships:

• <type> with expiration uses the underlying data store's time
• caveats are the only way to allow clients specify now timestamp

About caveats:

It requires clients to provide the now timestamp. This is additional complexity for clients.

Conversely, client-side provision of that value is crucial to our systems:

We use TimeProvider abstraction in .NET that serves as the central source of truth for time, meaning we always override data stores' internal clocks by explicitly setting time columns/fields.
Our TimeProvider is backed by different sources across projects, but what's important is that the app decides what now is, not any of the data stores or other infra.

Currently, <type> with expiration doesn't support our use case, but the caveat approach does. Caveats don't work for us because they feel like a regression from how neat <type> with expiration makes our prototype schemas in comparison.

Solution Brainstorm

If spicedb could be configured globally (or a schema directive is introduced, if that aligns better with internals) to require an otherwise optional now timestamp for all concerned write requests that target <type> with expiration.

Para-quoting Joey on discord:

Time skew has to be addressed:
Imagine if the client/caller started sending now timestamps of 72 hours ago to spicedb,
but spicedb already garbage-collected the "expired" relationships.
We could (in theory) require that the max skew be something like a few seconds.
Then it would be safe.