Allow limiting pipeline variables to a pre-defined set of values

[JeanMertz]

A pipeline variable is currently defined as:

struct Variable {
    key: String,
    description: Option<String>,
}

I propose changing it to:

struct Variable {
    key: String,
    description: Option<String>,
    values: Option<Vec<String>>,
}

By adding a values (open to bikeshedding, such as acceptable_values) field, we can optionally limit the accepted variable values to a pre-determined set of values when constructing a pipeline.

This can be useful, for example when you want a pipeline variable that consists of a boolean yes/no value, or a set of strings such as development, staging and production.

In essence, the value then becomes an untyped enum, checked at runtime.

This information can also be used by the UI to show a select field, instead of an input field, when the set of acceptable values are finite (and perhaps even dynamically make it a list of checkboxes, if there are three or fewer options to choose from, as that makes the UI more easy to use).

Not sure yet if we want to do anything special with a one-value enum, such as using a hidden field for the variable value, since only one value is acceptable, or just not accepting it as input when creating the pipeline variables, as I can't see any reason why you'd want to do that. But it's not that important to tackle right now.

In an ideal situation, variable values would be more strongly typed, so that more advanced variables become possible (arrays, objects, true enums, integers, etc), but that's still a long way off (and perhaps even undesired, as it adds more complexity to the system), and this will already be an improvement that enables more types of pipelines.

[JeanMertz]

This has been implemented.

Right now, the single value constraint will result in a checkbox that cannot be deselected, since all variables are currently required.

Once #25 is implemented, you can actually deselect a single-value constraint, if the variable is marked as optional.

(there are still some things to consider with optional values, such as should we add a "none" value to select boxes and radio fields? But we'll tackle those questions when we need to)