Prepare OptionsDiff for serialization

This is the first change in a chain that will allow using `OptionsDiff` in the serialization of `BuildConfigurationKey` objects.

A `BuildConfigurationKey` is needed in many different values serialized by Skycache (e.g., derived artifacts). Since their cache keys are obtained by fingerprinting the entire serialized value, any difference in the configuration stored alongside a file path forces us to store the entire value again, even if the path of the artifact itself is identical. With this and follow-up changes, we will be able to significantly reduce the number of novel bytes written to the cache between two invocations with different configurations, as long as they build the same targets.

We do this by either not storing the `BuildOptions` as part of the `BuildConfigurationKey` at all if it matches the baseline configuration present in the `{Serialization|Deserialization}Context`, or by storing a diff between the `BuildOptions` object being serialized and the baseline. Since these diffs are identical across different invocations in the majority of cases (even if the starting baselines differ), we are able to serialize many values to the exact same output bytes across builds.

This CL:
* Expands `OptionsDiff` to track metadata such as Starlark scope types and `onLeave` values, which are necessary to fully restore the original `BuildOptions` objects.
* Introduces the `applyDiff` method, which will be used during deserialization to reconstruct the target `BuildOptions` object by applying the diff to the baseline configuration retrieved from the context.
* Ensures that differing metadata does not affect the `ST-<hash>` path segments created by `OutputPathMnemonicComputer`.
* Updates the data structures used by the `OptionsDiff` class to be deterministic (e.g., using `LinkedHashMap` and `OrderedSetMultimap`).
* Additionally, `ListDiff` is designed to avoid storing the original baseline elements when they are entirely removed or reset in the transitioned options set. This allows a wider range of `BuildConfigurationKey` values to serialize to the exact same representation across builds.

A follow-up CL will introduce a codec for `OptionsDiff`. All the newly introduced logic for `OptionsDiff` will itself be leveraged in a subsequent CL that will introduce a custom codec for `BuildConfigurationKey`.

RELNOTES:none
PiperOrigin-RevId: 933579645
Change-Id: I8add341d87f833f839ce058a620036ac3aed02b9