Predefined key values

[AleF83]

I think that if we'll make statistics of key changes the vast majority of the changes will be rule values changes.

So I purpose to split between key rules changes (addition, matcher change or removal) and rule values changes.

I think we new concept of predefined key values.
I don't have anything concrete so I want to discuss the options here.

1. We can create new type of data in Tweek. It can be one dictionary, several ones or something more hierarchical.
2. We can allow to set dependent keys as value. In this case the dependent keys will be simple keys without rules. Just default value. Of cause they can be more complex but this is another discussion.

[Yshayy]

I think that Tweek type system currently sort-of support enums (by the allowValues attribute), also Tweek support both inline types and custom types (version is an example).
By allowing the types to be used in key values and not just in context values, we provide functionality that will also be more consistent with other experiences. (such as autocompelete dependent keys)

Some concerns we need to address:

• Tweek doesn't offer a UI for creating/inspecting custom types (such as https://github.com/Soluto/tweek/blob/master/services/git-service/BareRepository/source/manifests/%40tweek/custom_types/version.json), if we had that experience, we could've create a type and select it when creating a key.
• We might need to have a UI to convert a regular key to use inline custom type for better experience, it'll also probably be more common then global custom type.
• Does JPad just use the underlying base type?