Copy the Option before applying property values in handleProperties

[farkhalit]

DefaultParser.handleProperties calls processValue on the Option instance owned by the caller's Options rather than on a copy, so a value that arrives through the defaults Properties is written into the shared Option and stays there after the parse. Reuse that same Options for a second parse and the isValuesEmpty guard silently serves the first parse's value instead of the second one's, the value remains readable through options.getOption(...), and two threads parsing at once write the same values list. Parser.processProperties has the same write-through and also puts the shared Option on the CommandLine, so a later parse rewrites what an earlier CommandLine returns.

Both property paths now clone before storing the value, which is what the argv paths already do in handleOption and processArgs. The new test in AbstractParserTestCase fails for DefaultParser, BasicParser, GnuParser and PosixParser without the change.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.