Fix AddOption handling of spaces

[mwichmann]

Fix handling of AddOption for option-arguments with spaces (when omitting the = sign and/or when an option takes multiple option-arguments). Arguments unknown at the time the first pass splits the command line into arguments and targets would put such arguments into targets, and they remained there even after the AddOption calls were seen.

This is the final piece of the work from PR #3799, which was previously closed but noted as to be done.

Resolves #2748, resolves #2805, resolves #2977

NOTE: currently marked as Draft for two reasons which need resolution:

• The changes make SCons.Script.SConsOption.reparse_local_options unused. Should we get rid of that? (the referenced PR did propose to remove it)
• Documentation has some "don't do that" warnings about the problem this PR attempts to address. Should those warnings be removed, or perhaps softened?

Contributor Checklist:

• I have created a new test or updated the unit tests to cover the new/changed functionality.
• I have updated CHANGES.txt and RELEASE.txt (and read the README.rst).
• I have updated the appropriate documentation

[mwichmann]

Okay, as I look at the manpage note, I think that does need to be changed...

Note

As an artifact of the internal implementation, the behavior of options added by AddOption which take option arguments is undefined if whitespace (rather than an = sign) is used as the separator on the command line. Users should avoid such usage; it is recommended to add a note to this effect to project documentation if the situation is likely to arise. In addition, if the nargs keyword is used to specify more than one following option argument (that is, with a value of 2 or greater), such arguments would necessarily be whitespace separated, triggering the issue. Developers should not use AddOption this way. Future versions of SCons will likely forbid such usage.