multi_pip_parse should support platform specific requirement files

# 🚀 feature request

### Relevant Rules

I think we should extend the functionality of `multi_pip_parse` to deal with platform specific requirement files better.

### Description
Currently you can do this to have different lock files on different versions of python
```
multi_pip_parse(
...
requirements_lock = {
"3.10": "//:requirements_lock_3_10.txt",
"3.12": "//:requirements_lock_3_12.txt",
},
)
```
but the platform specific attributes take strings (and not dict) so you can only have a single requirements file on a specific platform
```
multi_pip_parse(
...
requirements_linux = "//requirements:requirements_lock_3_12_linux.txt",
requirements_lock = {
"3.10": "//:requirements_lock_3_10.txt",
"3.12": "//:requirements_lock_3_12.txt",
},
)
```
The platform specific requirements should also allow you to specify a dict so we can express the proper requirements files on various platforms

### Describe the solution you'd like
Ideally it would just look like this
```
multi_pip_parse(
...
requirements_linux = {
"3.10": "//:requirements_lock_3_10_linux.txt",
"3.12": "//:requirements_lock_3_12_linux.txt",
},
requirements_lock = {
"3.10": "//:requirements_lock_3_10.txt",
"3.12": "//:requirements_lock_3_12.txt",
},
)
```

### Describe alternatives you've considered
I'm not really sure there are any good alternative solutions, this feels like it is just missing functionality

The entry point is multi_pip_parse; start by tracing how requirements_lock and requirements_linux are declared and selected. Compare the existing Python-version dictionary handling with the platform-specific attributes. Done means platform-specific attributes accept the shown version-to-label mappings while preserving current string behavior.

Written by the indexing model from the issue text.