fix conflict specification included in module files

fix conflict specification included in module files (see #994), base it on short module name obtained from active module naming scheme

this forced me to resort to another solution for verifying toolchain definitions vs the loaded toolchain module, since this basically means we can no longer obtain the (isolated) software name from a given module file (keeping in mind that a custom module naming scheme may be embedded a software name in some weird way)

the inner function `tc_elem_present` now using a regex to check whether a module name *could* be for a software package with the specified name, which is the best I can come up with

this approach should work most of the time, but it possible to come with a (weird) module naming scheme that breaks the assumptions made in `tc_elem_present`...
we don't enforce being able to reverse the naming scheme yet, i.e. go from module name to software name/version and toolchain name/version; not only software name, we will need all four in the end (and even `versionsuffix` too)

I was also thinking to simply ask the module naming scheme what the software name is for a given module name. But then we need access to `ActiveMNS` here in `toolchain.py`, which brings back the cyclic imports issue...

If you agree this is the best approach (adding something like `software_name_from_module(mod)` to the MNS API), then I can make this work.