feat: Add key/value pair validation

[Techassi]

Fixes #614, supersedes #615, part of stackabletech/issues#188

This PR adds mechanisms to safely create key/value pairs (labels and annotations). These enable us to attach a unified set of labels to deployed resources. The set of labels make it to possible to track resources installed by us, which in turn enables us to list, modify and delete resources with our management tools, namely stackablectl, and in the future stackable-cockpit.

## Tasks - [x] Move `stackable_operator::label_selector::convert_label_selector_to_query_string` into `kvp` module - [x] Remove all temporary `unwraps` - [x] Add doc comments to all new structs, modules, types, etc... 

[Techassi]

We ideally want the creation of a K/V pair to be available in const environments. With the current approach making use of the (non-constant) FromStr trait, this is not possible. We might be able to sidestep this using a non-trait solution (until const in traits are stabilized and available). This however requires a more sophisticated parsing process, which looks at individual bytes without allocating.

Having K/V pair creation available in const environments would allow us to define common labels/attributes in operator-rs (or any other operator repository) which are parsed and validated during compile time. That would be huge, but at the moment rather cumbersome to implement.

The API is very close to it's final form. One open point is the usage of the new API in other operator-rs code, like the k8s resource builders. An important design decision is to make the usage through these functions convenient to use while making sure the K/V pairs are valid.

[NickLarsenNZ]

Looks really good

[NickLarsenNZ]

lgtm

[nightkr]

When would the former API be used? What hole is it trying to fill?

[Techassi]

There is currently no immediate benefit from the first option, but in the future we might stumble over that kind of input, like from a file, or command line argument.

[nightkr]

Then we can consider the problem when it actually arises. We shouldn't preemptively make it easier to do the wrong thing just in case.

[NickLarsenNZ]

LGTM. I like the contains and contains_key that take an impl TryInto. Makes the usage really clean.