Passing arbitrary linker flags after --linker is removed

[SeanTAllen]

Phase 7 of the embedded-LLD migration (#4941) removes --linker and --link-ldcmd. Embedded LLD becomes the only linker, and there's no longer a way to substitute an external one. That closes a door we should talk about before we walk through it.

--linker did more than swap linkers. People reached for it to pass things through to the link step. The website FAQ spells out the pattern: replace the whole linker command with one of your own and append whatever flags you need. Linking a library that isn't a Pony dependency, adding a search path, handing the linker some option ponyc doesn't model. The mechanism was crude (you replaced the entire command and hoped the rest still lined up) but it was the only seam we offered.

Most of what people used it for, we already cover a better way. use "lib:Foo" links a library by name. use "path:/some/dir" adds a search path. Those go in your source where they belong, travel with the code, and work the same on every platform through embedded LLD. If you were using --linker to pull in a library, that's the answer, and it's a better one.

What's left is the arbitrary case. A raw linker flag, something like -Wl,--no-as-needed or a -z option or a flag for some linker behavior ponyc has no model for. With the external linker gone, ponyc builds the entire argument vector itself, and there's no point in that vector where a user flag gets spliced in. Today that capability has no replacement.

So the question: do we want one, and if so, what shape?

A few directions, not a menu to pick from, just to frame the space:

• A pass-through option (--link-flag=..., repeatable) that appends raw arguments to the embedded LLD invocation. Simple, familiar, and it puts the burden of correctness on the user, same as --linker did. The risk is that it leaks LLD's flag surface into ponyc's interface and invites bug reports that are really linker questions.
• A use directive for linker flags, the way we already do libraries and paths. Keeps the knowledge in the source, but a raw flag is a lot less portable than lib: or path:, and baking a GNU-ld-ism into a use statement ages badly.
• Decide the arbitrary case isn't worth supporting. use "lib:" and use "path:" cover the cases we can reason about; past that you're doing something ponyc doesn't intend to support, and you can wrap a build step around it.

The named-library case is handled, and from the usage we've documented that's most of it. The open question is whether the arbitrary-flag path is load-bearing for anyone in a way we'd be wrong to drop, and if it is, which of these shapes (or another) is right.