Remove Runtime.current_execution_environment & co.

[JaroslavTulach]

Trying to replace the current EnsoContext.getExecutionEnvironment with a solution based on State as described at #12294 reveals some issues.

According to the specification @jdunkerley wants to achieve:

• Mostly inside Enso we use if_enabled to control when we run code
• We use with_enabled to allow us to turn on for blocks of code.
• There is a play button at a node and workflow level in the GUI allowing temporary enabling via the language server - Run node in a different execution environment #11173

current_execution_environment

I guess I have to start questioning the basics. Why do we have Runtime.current_execution_environment? When I look at the usages, I don't see any reason why such a method should exist:

• if I managed to remove this method
• then environment argument would have to go away as well

environment argument

I am questioning the environment argument of the Context.is_enabled method

• we don't use it anywhere
• what does it suppose to mean?

If Runtime.current_execution_environment can be removed, then we can remove also environment argument.

Environment vs. Contexts

My view of the system:

• various Runtime.Context instances (Input, Output, etc.) are the key concept
• environment is just a "human friendly name" for a set of Runtime.Context instances
• environment is used from CLI (as an argument)
• environment is used from GUI (as a button)
• but:
• before passed to engine it is converted to set of RuntimeContext instances
• engine, libs code only works with Context.Xyz.is_enabled & co. methods
• never need to know anything about the "human friendly names" of sets of Runtime.Context instances

The implementation of #1173 is currently changing (the name of) the current environment. Now I believe that is not correct...

Guessing Dmitry did that to enable running a single node with Write enabled (a very nice feature)

... rather than changing the environment (e.g. human friendly name of set of Runtime.Context enabled instances) the language server should turn on Runtime.Context.Output - e.g. temporarily calls Context.Output.with_enabled before evaluating the given node.

I believe it would look the same from user perspective and would be less braided internally than what we have right now.