Allow pluginsystem to configure general key-value pairs pr forward model step

[berland]

Some forward model steps require certain configuration parameters to be set. This could be environment variables or PATH prefixes, or any other.

Today, such options can be set through the site-configuration which can add SETENV lines to every Ert run, yielding environment variables available when running the forward model.

To avoid leaking configuration between unrelated forward models, it should be possible to specify environment variables to specific forward model steps, distinguished by the forward model step name (which might be run repeatedly).

Having this as a hook also enables other parts of Ert to access this information. This is relevant for e.g. eclrun validation which queries itself for available versions.

Open questions:

• Should we only allow upper-case keys, since we want to expose this to each step via environment variables?
• Should we expose only upper-case keys through environment variables?
• Should we allow values to be any Python type (but str(value) when exposed through env)

[sondreso]

• Should we only allow upper-case keys, since we want to expose this to each step via environment variables?
• Should we expose only upper-case keys through environment variables?

I think we allow arbitrary keys (but convention dictates using lowercase) and we expose them as upper-case keys in environment variables.

• Should we allow values to be any Python type (but str(value) when exposed through env)

I think this makes sense, but it should be documented that we will call str(value) when exporting to env, and that it needs to adhere to any limitations that environment variables have.

[berland]

Another corner case is when different plugins set configuration for the same forward model step name. This should in general be allowed. The configuration should probably be merged.

Conflicts for keys should result in hard errors since plugin order is arbitrary (effectively). Uniqueness of keys must be handled case-insensitively.

[berland]

It must be assessed whether how this feature interacts with exec_env,

• Deprecate EXEC_ENV #1882
• https://github.com/equinor/rms-sys/issues/96

[berland]

It must be assessed whether how this feature interacts with exec_env,

This will not interact with exec_env, but when merged, it provides forward model step authors with the necessary tools to get rid of using exec_env.