consider generalized toolchain module

the "cpp" module currently serves as a catch-all module for native compilers, because it effectively represents the toolchain. this is already mildly misleading for c-like languages, and would be highly confusing if for example support for fortran was added.

the first thought is "let's split it by language" (we could still share code behind the scenes, so it's only about the interface for now).
but here's the problem: there are lots of properties one wants to declare project-wide, irrespective of language.

so one idea is to split the modules into multiple frontends and one backend. e.g., language standard version goes to a specific frontend, while optimizations go to the shared backend module (let's call it tc, for toolchain).
but requiring the user to remember all the time which property belongs where is counterproductive, especially as some shared properties actually belong to the frontend. and then there are degrees of similarity - c and c++ are likely to share many more frontend options than c and fortran.

maybe this will work:

• common tc module (for the time being, cpp can be aliased to it)
• specific languages are pulled in with the submodules property. the default can be plain c or even nothing (most projects use CppApplication and other template items anyway)
  • as these are regular module dependencies, it is possible to declare them being optional, which is relevant for QBS-346
• the submodules create nested namespaces which can contain language-specific properties (tc.cxx.version) or override toolchain-wide properties (tc.warningLevel vs. tc.cxx.warningLevel)
• it indeed would make sense to create "family" namespaces like tc.all_c, tc.all_non_cxx (c and objc), tc.all_cxx (c++ and objc++), ts.all_non_objc (c and c++), and tc.all_objc (objc and objc++) when the respective languages are requested. there is no strict hierarchy, so new namespaces can be created when they are actually needed (i don't think all examples i've listed even make sense).

this would be seriously complicated by it ever being necessary to use multiple toolchains (covering different languages) within the same Product.