Add text discussing the approach to flavors.

Created by: garloff

In short, the naming proposal serves two purposes. (1) Provide transparency on features/details/capabilities (2) Allow users to chose the right features

There is not really good alternative for (2) to create names. We have chosen a systematic approach to it, which allows to generate/parse this programmatically (and manually if you are familiar with the spec), but which can lead to rather complex names in extreme cases.

To only achieve (1), better ways exist by using metadata (extra_specs). So smaller providers that don't need users to chose between so many flavors don't need to encode all the details in the name, but could use short names (which is allowed by the spec) and make details discoverable via a to-be-written metadata spec. This is the suggested approach going forward.

This is an attempt to address #73 (closed).

Signed-off-by: Kurt Garloff kurt@garloff.de