make get_opt truly ignore unknown options

way early in the development of Configman, a challenge was to get the standard commandline tool module ```get_opt``` to ignore unknown command line switches.  It is possible (probable) that the user specified command line options that haven't been until defined deep into the iterative overlay process.  ```get_opt``` has to ignore them, otherwise the exception that it raises would stop Configman dead before it could complete its work.

That original implementation unwisely took unknown command line switches and put them into a the same list that was later used to store non-switch command line arguments.  The result was that if there was an optional command line argument for which the user did not specify a value and there were switches on the command line that would not be valid until later in the overlay process, then those undefined switches would get inadvertently used as values for the unspecified command line arguments.  That was bad.

say we had this situation:

```
$ my_app --help
usage: my_app [ arg1 [ arg2 ]]
...
$ # say arg1 specified a class that would bring the command line switch --alpha
$ my_app AlphaClass --alpha=27
```
At the beginning of the overlay process, we have only two options: ```arg1``` & ```arg2```.  In the first round of the iterative overlay process, get_opt doesn't know that --alpha=27 will be valid in future, but it does know that it is invalid now.  ```arg1``` gets the value ```AlphaClass```.  Because the ```for_getopt``` module was putting unknown switches into the arguments list, ```arg2``` was getting the value ```--alpha=27```.  In the next iteration of the overlay process, ```--alpha``` became a legitimate switch because AlphaClass defined it in its required_config.  This time ```get_opt``` reinterpreted the switch and successfully set its value.  

It was too late for ```arg2```, though.  It had been given a bad value in the first round.

This PR fixes that problem.

while it could be easily argued that consistency with the previous test would be appropriate, I couldn't bear calling a method when just subscripting was good enough.  Clearly either form is better than what was there.