[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early

["slyfox at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527

--- Comment #2 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Hm, but the COLLECT_GCC_OPTIONS variable is only used for communicating
> between the driver and the linker, the options therein are individually
> passed to the program execved?

AFAIU the driver sets `COLLECT_GCC_OPTIONS` variable and never unsets it. As a
result it affects all the `exevce() calls. Be it `cc1`, `as` or anything else
regardless of the fact if it uses the variable or not. `cc1` is probably the
first casualty.

As a simplistic example here we break `ls` with too large environment file:

    $ COLLECT_GCC_OPTIONS=$(printf "%0*d" 200000 0) ls
    -bash: /run/current-system/sw/bin/ls: Argument list too long

> You are maybe looking for the -f*-map options to take a file as input
> containing multiple mappings?

`NixOS` is also occasionally hottong the same limit by passing too many include
an library paths:

    -I/nix/store/hash1-foo/include
    -I/nix/store/hash2-bar/include
    ...
    -L/nix/store/hash1-foo/lib
    -L/nix/store/hash2-bar/lib
    ...
    -Wl,-rpath,/nix/store/hash1-foo/lib
    -Wl,-rpath,/nix/store/hash2-bar/lib

I wonder if we could solve all of these limitations here by at least avoiding
`COLLECT_GCC_OPTIONS`.

But otherwise if generic fix is too invasive change then passing a mapping file
should do as well.

What would be an acceptable for of the file? A new option, like?
    -fmacro-prefix-map-file=./foo
with entries of exactly the same form
    $ cat foo
    /nix/store/hash1-foo=/nix/store/00000000-foo
    /nix/store/hash2-bar=/nix/store/00000000-bar
    ...

Or maybe reuse existing -fmacro-prefix-map= and use response-style file input?
Like -fmacro-prefix-map=@./foo.

clang would probably need the same handling if we were to extend the driver.