Task-util-config: it should be possible to set a default value for a parameter that depends on one or more parameters different from current value

- Kind of request: RFC of a feature request

# Problem
Currently the wizard doesn't allow the developer to specify the default value for a single item based on values of other parameters.

## Example 1
The minimum amount of RAM to allocate depends on the chosen services.
- If the final user wants to install only PostgreSQL, then the wizard should suggest a minimum amount of RAM (let's say 16 GB).
- If the final user wants to install only PostgreSQL and MinIO, then the wizard should suggest a different minimum amount of RAM (let's say 22 GB).

## Example 2
A string might need to be the concatenation of names previously input.
- If a variable ORGNAME name is specified as "ACME", and another variable CLUSTERNAME is specified as "FINANCE", then the suggested value for a variable NODEPREFIX is "ACME-FINANCE".

The implementation of this feature should affect all the types:
- string
- int
- float
- bool

# Impact
100% of users that will install the ops would find much easier to install Open Serverless.

# Priority
low

# Suggested solution for the example 1:

```
"POSTGRESENABLED": {
"type": "bool"
},
"MINIOENABLED": {
"type": "bool"
},
"MINRAM": {
"type": "",
"default-function": "calcMinRam"
}
```

and somewhere else (I show some pseudocode, it might be Typescript):

```
calcMinRam() {
if (POSTGRESENABLED == True and MINIOENABLED == False {
return 16;
} else if (POSTGRESENABLED == True and MINIOENABLED == True {
return 24;
}
```

If the function specified in "default-function" doesn't return a suitable value (e.g. NaN), a default value can be considered (see https://github.com/apache/openserverless/issues/61)

With
POSTGRESENABLED not enabled
and
MINIOENABLED not enabled the calcMinRam function wouldn't return a suitable value so the value 14 should be considered (see example below):

```
"MINRAM": {
"type": "",
"default": "14",
"default-function": "calcMinRam"
}
```

## Alternative solution
The implementation of this feature request might be overly complex.
Alternative solution: an explanation in the label might be enough.