[core-kit] Autogen `sys-devel/gcc` (at version 14, at least; RFC)

Nobody has claimed this yet.

It turns out that creating a `gcc` autogen is not particularly challenging. We can start from our existing ebuild for `gcc-12.3.0` and pare it down a bit, culling the `multilib`, cross-compile, and `prefix`--related code. I've done most of this work already in a static ebuild for `gcc-13.4.0` and `gcc-14.3.0`; and have used the results to build `mark-unstable` and `mark-xl` `stage3` tarballs, with some local additions to (among other things) boot them in a VM.

I think we should aim for `gcc-14.3.0`. Debian stable is at `gcc-14.2.0`, so that one is a reasonably good baseline version. Despite that `gcc-13.4.0` will require fewer package updates in our tree for stabilization, we will not be able to stay there long if we want to keep updating our KDE6 autogens, since upstream will require `gcc-14` soon. We could try `gcc-15` also, but reportedly it will cause many more problems than `gcc-14` and I think we'll be happier to let other organizations with more resources deal with them first. What do others think about the version target? We can even generate multiple versions in `mark-unstable`.

Aside: Should we move this package to `dev-kit`?

Start with the existing sys-devel/gcc ebuild for gcc-12.3.0 and compare the static gcc-13.4.0 and gcc-14.3.0 ebuilds described in the issue. Review the resulting mark-unstable and mark-xl stage3 builds; done requires agreement on the target GCC version and whether the package belongs in core-kit or dev-kit, followed by a working autogen.

Written by the indexing model from the issue text.