Currently cannot support multiple languages or non-clike languages

I've been thinking about replacing pkg-config a lot, and one of the real short comings of pkg-config is that it assumes C (and C++ and ObjC kinda work because of that), but trying to use a newer language like Rust, Zig, or D is pretty painful, or just impossible. CPS kinda supports non-C languages through it's `Type: "jar"` mechanism, but that means each language has to be hard coded. It also means that you have to duplicate keys like `c-runtime-vendor` and `cpp-runtime-vendor`. I'd propose instead something like this:
```json
{
"platform": {
"languages": {
"c": {
"runtime-vendor": "gnu",
},
"rust": {
...
}
}
},
"components": {
"sample": {
"language": "c",
"type": "dylib",
...
}
}
}
```

This necessitates a couple of things: that the keys and their values in each component are language specific:" ie, rust doesn't provide a rust dynamic ABI, only a rust static lib ABI, but a component can be built with rust that provides a C ABI.

I think that solving the problems of future languages is really critical to making anything replacing pkg-config a success.

No files, tests, or implementation entry points are named. Start by reviewing the existing CPS specification and its treatment of language-specific components, then determine how the proposed languages structure would fit. Done means agreeing on a language-agnostic schema and its ABI and key-value semantics for current and future languages.

Written by the indexing model from the issue text.