Add specs for changes surrounding "next" desired sharding key

What does this MR do and why?

We are introducing a concept of "next" desired sharding key. It is like today's desired_sharding_key concept, but these are for tables that:

• have a non-nullable parent association
• but the parent association does not have a fully backfilled sharding_key yet. It only a desired_sharding_key set now, but it will be eventually backfilled, and when that is completed, these tables can inturn backfill from that parent association. See this for an understanding of how this will work.

We use awaiting_backfill_on_parent: true to distinguish between these type of desired sharding keys and normal desired sharding keys.

You can see the diff in the POC MR to see how these will be generated: !145135 (diffs)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Related to #442385 (closed)