Cesium should support Response Files to avoid the shells command line limitations

There is an inter-language tooling spec about tooling interoperation: github.com/ecostd - which has begun to evolve apart of the ISO C++ Standard to simplify the work on specification and untie it from C++ to make spec cross-languages available.
The Response Files (RSPs) are the standard work-arounds for shell command line length limitations, but every major C++ compiler (like GCC, MSVC, Clang (it also has at least two formats of RSPs) has its own format. The [P3051R2](https://wg21.link/P3051R2) C++ proposal defines the standard format for RSPs based on JSON (with Json Schema).
TL;DR of this proposal (other than previous paragraph):
- Use known JSON format for all tooling;
- The old flags are supported via `arguments` array inside JSON
- The **logical** compile/link features are supported via `options` object with reserved `std.****` params (currently there is only `std.param` defined for composing multiple RSPs either by inheriting "before", or appending "after" current file:
> Additional response files can be inherited by specifying a { "std.param": { "pre": [ "file.json" ] } } option. Or they can be appended by specifying a { "std.param": { "post": [ "file.json" ] } } option.

These files are meant to be generated by tooling: build systems (like CMake, it has its own logic for these files somewhere here: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmSystemTools.cxx#L638 ), package managers and even compilers (e.g. some offloading use-cases like nvcc + gcc). Also these files often written by humans in case of long command lines. How tooling/people would know which features are suppported by tool - is, obviously, determined by the tool's documentation, and how tool itself - and its ability to "reflect" it, e.g.: `--help` command line flag, or another EcoStd paper about tools introspection 😀 - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2717r5.html (this paper is evolved into RFC: https://github.com/ecostd/rfcs/pull/2) - but this is an another interesting story...

The plan for feature is:
- [ ] Add the `--std-param:` flag;
- [ ] Add the simplest `arguments` form as a transitional way;
- [ ] Add the ability to compose multiple RSPs (`std.param` option);
- [ ] Think about Cesium-specific compile/link options and reserve the "cesium.****" option placeholders;
- [ ] Support our own options (as the "std.***" options are not defined for now..)

No implementation file, test, or entry point is named. Start by reading the linked P3051R2 proposal and tracing Cesium's command-line parsing and compiler invocation paths. Done means agreeing on a scoped phase of the checklist and supporting the specified response-file behavior with coverage for the chosen format and composition rules.

Written by the indexing model from the issue text.