Support multiple platform parents

### Description of the feature request:

According to the [platform inheritance](https://bazel.build/reference/be/platform#platform_inheritance) document, a platform can have an array of parents, but only 1 parent is currently supported. This feature request is about adding support for multiple parents. This is not a feature we need any time soon, just filing the bug so we don't lose track of the work required.

### What underlying problem are you trying to solve with this feature?

ChromeOS uses [portage overlays](https://source.chromium.org/chromium/chromiumos/overlays/board-overlays/+/main:overlay-guybrush/metadata/layout.conf;l=6;drc=1a7de97efa7d7bddef842b761c87598f62340f47) for defining config. Each overlay can have multiple parents.

An example of the guybrush-private overlay:

masters = portage-stable chromiumos eclass-overlay chipset-cezanne-private cheets-private guybrush

This means that the default values are constructed by traversing each parent and applying any overrides. While most of this can be flattened into a single hierarchy:

i.e.,

portage-stable -> chromiumos -> eclass-overlay -> chipset-cezanne -> chipset-cezanne-private -> guybrush ->guybrush-private

We run into a problem with cheets-private. cheers-private contains the config values for enabling the Android Runtime Container on ChromeOS. So it's more of a feature that we can pull in when applicable. If I was modeling this with platforms, I would ideally have guybrush-private have two parents, guybrush, and cheets-private.

One thing I'm not sure how to handle is the `private` and `public` inheritance. public builds don't have access to the `-private` overlays. Modeling the `public` chain is simple:

guybrush -> chipset-cezanne -> eclass-overlay -> chromiumos -> portage-stable

The private graph gets a little complicated though because we end up with a diamond on `chipset-cezanne`.

guybrush-private
-> cheets-private
-> guybrush -> chipset-cezanne
-> chipset-cezanne-private -> chipset-cezanne

In theory we could make `chipset-cezanne-private` not depend on `chipset-cezanne`, but I don't think it hurts. I think the algorithm would need to treat the first parents listed as low priority and the later parents with higher priority when computing the value.

### Which operating system are you running Bazel on?

_No response_

### What is the output of `bazel info release`?

_No response_

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse master; git rev-parse HEAD` ?

_No response_

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

_No response_

Start with the linked Bazel platform inheritance documentation and trace how the current single-parent platform behavior is implemented. Define and test support for multiple parents, including inheritance priority and the diamond-shaped private-platform graph described in the issue; done means those configurations resolve values predictably without breaking public chains.

Written by the indexing model from the issue text.