Serve iframe from django + resurrect iodide local-only dev environment

[wlach]

• The iframe is now served via django from the special /notebooks/eval-frame/ endpoint. This is architecturally a little cleaner and paves the way towards Iodide should not hardcode server addresses #1943
• For testing changes to the editor only, you can now use the (renamed)
  "simple-serve" command.

Pull Request checklist

• Documentation: If this feature has or requires documentation, the relevant docs have been updated.
• Changelog: This PR updates the changelog with any user-visible changes.
• Tests: This PR includes thorough tests or an explanation of why it does not

[wlach]

@bcolloran please review js parts (python portions optional)
@jezdez could you review the python changes? (and their interactions with the js parts, if you feel up to it). likely a prereq to reviewing is understand the "iodide content in an iframe model" that we have -- either me or @bcolloran could explain this. maybe we could go over it in the iodide meeting tomorrow if you'll be around
@robotblake this is more an FYI than anything else, but grepping through the PR for "middleware" might highlight areas of concern from a deployment POV

[robotblake]

I don't see anything I'd be concerned about off the top of my head.

[bcolloran]

All seems to work as desired in the django + npm run start mode.

in simple-serve mode, there seems to be a port mismatch somewhere -- i'm getting:
Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘http://localhost:8000’) does not match the recipient window’s origin (‘http://localhost:8080’).,
and the eval-frame is not loading. for simple-serve, you might still need to tweak IODIDE_EVAL_FRAME_ORIGIN and IODIDE_EDITOR_ORIGIN in webpack or something like that?

[bcolloran]

(oh also: there aren't really an JS changes yet in this -- i expect you have other stuff coming in follow-up)

[wlach]

@bcolloran the port issue comes from the fact that currently webpack is picking up some stuff from .env, where we had specified these values with our dockerflow-based environment in mind. Oops. For now I'll address this by just serving from port 8000 again, as we do for the internal server -- we can change this later after I move to the next phase of this work, which is to stop specifying server names inside our webpack-generated js altogether.

[bcolloran]

sounds good, thanks will

[rafrombrc]

Looks pretty straightforward to me, +1.