Support Elixir expressions in Playground

[xxdavid]

Implements #520.

This is a partially working implementation. There are probably unnoticed bugs and edge cases when it does work, but it works quite well in a lot of cases.

All attribute types are now editable. When Elixir expressions are expected, there is an Elixir-like icon visualizing that the input must be Elixir code. The icon goes red when the code is not valid and its title says what the error is. Textareas are used for these inputs, so that user can make them bigger.

The Elixir evaluation uses Dune under the hood. Therefore, the evaluation is relatively safe. However, there are two issues I noticed. The first one is small – structs cannot be constructed as their syntactic form is forbidden (don't know why). This can be fixed by implementing a custom Allowlist. The second issue is more important. To prevent atom exhaustion, atoms that don't already exist are translated to atoms like : a__Dune_atom_1__. Although not fatal, this considerably lowers the usability. Maybe we can say that the expression evaluation in playground should be enabled only on local machines without remote access and then just use Code.eval_string/1…

TODO:

• Polish code
• Fix bugs
• Tackle the Dune drawbacks
• Make the expression evaluation configurable (off by default)
• Write tests

[cblavier]

Looks amazing!
Do you think you can mix dune code evaluation with Code.eval_string/1 to circumvent atom limitations?

[xxdavid]

Yep, I think we could do something like

  defp eval_expr(string) do
    case Dune.eval_string(string) do
      %Dune.Success{} ->
        {evaluated, _binding} = Code.eval_string(string)
        %Expr{value: evaluated, string: string}

      %Dune.Failure{message: error} ->
        %Expr{string: string, error: error}
    end
  end

This would still prevent doing things like File.rm_rf!!("/") or File.read!("secret_file") or System.get_env(), but would allow shutting down the BEAM instance by atom exhaustion (and also evaluates the expression twice). We need to choose between these tradeoffs. What solution out of

1. Dune only
2. Dune + Code.eval_string/1
3. Code.eval_string/1 only
   sounds best to you (neither of them is ideal)?

[cblavier]

I'm not super fond of Dune-based solutions which are either half-functional (no atoms) or half-secure (can crash the VM)
I would rather use Code.eval_string/1 without Dune, but only for the dev environment.
WDYT?

[xxdavid]

Running just Code.eval_string/1 seems okay to me if we warn users enough not to use this in production. Would you also create the new option, or just always enable it in the dev environment and that's it?

[cblavier]

It can default to enabled in dev, disabled otherwise.

We already have this kind of default behavior with compilation_mode defaulting to :lazy in dev and :eager in other environments.

phoenix_storybook/lib/phoenix_storybook.ex

Line 198 in c61c558

defp compilation_mode(opts) do