Make supported component library names explicit

[simu]

Context

Currently, the documentation (and the code) implicitly support arbitrary names for component libraries, cf.

commodore/commodore/dependency_mgmt.py

Lines 29 to 32 in ab7c8a5

	for file in component.lib_files:
	if cfg.debug:
	click.echo(f" > installing template library: {file}")
	relsymlink(file, cfg.inventory.lib_dir)

and

commodore/docs/modules/ROOT/pages/reference/concepts.adoc

Lines 44 to 45 in ab7c8a5

	Components can optionally provide Jsonnet libraries which can be used by other components.
	To allow Commodore to make component libraries available to other components, they must be placed in directory `lib/`.

However, the component template will create a component library which matches the component name, if enabled, cf. https://github.com/projectsyn/commodore/tree/master/commodore/component-template/%7B%7B%20cookiecutter.slug%20%7D%7D/lib

I thought we had documented that we officially only support component libraries which match the name of the component (see e.g. appuio/component-openshift4-monitoring#79), but this appears to not be the case.

Instead of keeping the current state, we should decide explicitly what we want to support, and make sure that the documentation and code reflect that decision.

Acceptance criteria

• We've decided what names we want to support for component libraries
• Commodore prints a deprecation warning if a component uses a library name which is not supported
• The documentation is clear on what we support and what we don't support

Options going forward

1. Keep the current state, but document it more explicitly. In this case we'd have to figure out a way to handle conflicting library names, e.g. using jsonnet-bundler's approach of providing a top-level symlink for one of the conflicting libs, but still providing both of them in "absolute" (read: prefixed) paths.
2. Restrict components to only be allowed to provide a library whose name matches the component name. This would ensure that there's no name collisions, as compnent names must be unique. However, this would disallow tricks such as providing generic interfaces for distribution-specific implementations (e.g. rancher-monitoring vs openshift4-monitoring) by having the components provide libraries with the same name, as we can be reasonably sure that we'll never include both rancher-monitoring and openshift4-monitoring for a single cluster.
3. Allow components to use arbitrary names as long as they're prefixed with the component name. This avoids name conflicts, but is probably not very ergonomic for users, as component library names would tend to be quite long.
4. Restrict components to only use library names which are prefixed by the component name by default, but introduce a mechanism through which components can advertise aliaes for their component libraries. This gives us namespacing by default, while still allowing components which implement the same interface (e.g. monitoring stack) to expose their component library under a generic alias.

[simu]

We've decided in Tarazed that option 4 (component name prefix by default, support for explicitly advertised aliases) is the best trade-off and will go ahead with that option.