Teach ParseFlags to understand non-gcc compiler's options

[mwichmann]

At the moment, MergeFlags calls ParseFlags, which only understands the syntax of gcc-style compilers. The documentation even says so in the first sentence:

https://scons.org/doc/production/HTML/scons-man.html#f-ParseFlags

Old issue #2808 missed this, and reported misbehavior after calling env.MergeFlags(['/TP']). Since ParseFlags doesn't recognize that option, it put it in LIBS instead, leading to a build fail (in a configure test, where the source of the problem is semi-hidden and not so easy to spot):

Any other strings not associated with options are assumed to be the names of libraries and added to the $LIBS construction variable.

It wouldn't be that hard to have tables of options and what should be done with them for other compilers, notably msvc, which of course has a completely different set. At this point, no proposal of what that would look like - would it somehow be toolchain-associated, so a particular option set only works if you're using that toolchain, or expanded so lots of different options are recognized in one big check, or what? This is just to get the concept recorded.

[bdbaddog]

Might be simplest for compilers to add/alter the existing list when they're generate()'d

[mwichmann]

Might be simplest for compilers to add/alter the existing list when they're generate()'d

In theory, yes. But have to account for some args needing an opt-arg, and others not, so probably a bit of rework still needed in ParseArgs.