Fix bugs in option application to module-set modules.

Handling options for the modules generated from a module-set has always been
especially clunky, and at some point even the hacks failed and it became
impossible to do things like setting an option for a specific module picked out
of a larger module-set.

E.g. the idea was always that the following would work:

    module-set foo
        repository kde-projects
        use-modules kdelibs kde-workspace kde-runtime
        cmake-options -DCMAKE_BUILD_TYPE=Release
    end module-set

    # Override the above, but only for kde-runtime
    module kde-runtime
        cmake-options -DCMAKE_BUILD_TYPE=Debug
    end module

Probably I should have named "module" as "options" or even "override" (and
that's still feasible), but in any event this has been broken for awhile:
whenever kde-runtime is built it would end up with a Release build type instead
of a Debug one.

Worse yet, the second mention of kde-runtime was handled as a separate module.
Usually this duplicate module was weeded out by accident during the dependency
resolution phase, but that leaves open the question of which internal Module
object was the "winner"... now we can't even rely on the option handling being
predictably broken.

This was partially helped by c565d4c7 which at least prevents the code from
spitting out duplicate modules from within a given module-set (which is quite
easy to do by accident with kdelibs).

This commit reorganizes the command line and option reading code to do the
following:

- Add a "pending option" tracker, to hold option values that should be applied
  to a named module, if one happens to be created, either via explicit
  module-set expansion (e.g. if you ask for nepomuk-core or nepomuk-widgets) or
  via implicit expansion (e.g. if you ask for kdemultimedia, you get juk and a
  lot of others).
- Add a "selector" method which is responsible for translating module entries
  on the command line into appropriate module-set or module selections from the
  Modules and ModuleSets read in from the rc-file.
- Pass a subroutine to the module-set expansion method and the selector method
  to ensure that any new Modules created as a part of either process are checked
  for pending options (either from the rc-file due to the "override" module
  method, or from the command line.
- While I was digging it out I made the long-overdue switch to Getopt::Long
  away from my custom option parser. There are a couple of minor features lost in
  this process but if they are needed I can add them back.

Now it should be possible to override options for individual modules within a
module-set. However as before, the module you wish to override *must* have been
mentioned somewhere before in a use-modules entry so that kdesrc-build can
recognize that it must hold onto those option values for later application. It
is still safe to mention a kde-projects module and its superset, they will be
re-ordered if necessary.

BUG:321883
FIXED-IN:1.16