Improve libraries target types to avoid redundant configuration

[GPMueller]

I believe the distinction between static and shared libraries should not be made where the library target is defined. Instead, the consumer should specify how the library should be consumed.
The library types to consider are:

• header only
• object (only object files are built, nothing is linked)
• static
• shared

Adapted inheritance rules would allow a concise, clear definition of a library target, which could then be consumed consistently by other targets, without as much need to separately treat static and shared library targets.

Implementation requirements:

• a way of defining whether a dependency should be built & linked as object, static or shared. Maybe:
  • use a dict: dependencies: [shared=[...], static=[...], object=[...], header-only=[...]]
  • use different keywords: dependencies_static: [...]...
  • default to static for buildable libraries and allow specifying dependencies: [..., shared=[...], object=[...]
  • specify a "preferred" linkage, which can be overridden, e.g. if a consumer wants to link statically
  • a CLI parameter, which defines what should be built
• a way of building a library as a specific kind (e.g. if we want to redistribute a library, not an executable, we need to build it irrespective of how it is linked into other build targets). Maybe:
  • ?
• flags.link would have to be turned into interface-flags.link when building a static library (flags.compile can remain). Instead of inheritance rules per target type, we would have rules per dependency type.

The first point is particularly important to decide, as it defines the problems and special cases...

Problems:

• some libraries require flags to be specified, e.g. glfw requires _GLFW_BUILD_DLL to be defined for shared library builds (I believe this to be bad practice)
• target definitions become more implicit and proper usage of clang-build would require a little deeper knowledge of the rules around library targets

Questions:

• how will the case executable ---static---> library ---> shared library be treated (especially when the shared library is system-installed or downloaded binary)? This would need to be properly documented, as the user might expect no dynamic dependencies because static linkage of the executable was defined
• how should the "consumer" use header-only versus other libraries that need to be built & linked
• how to build a library specifically as a shared, static or object library, when it is not depended on? Better CLI options may be needed. Improved CLI options for this could also help with specifically building the tests or examples of one specific target.
• what would be the inheritance rules of object libraries?
• how to treat system libraries (see also How do we link to libraries installed on the system (like boost and others)? #41)?