Move security article out of drafts

[toddjonker]

Description

This is good enough to make public.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[toddjonker]

@rationull per recent conversation I'd welcome any feedback on the current content here.

[rationull]

I'll take a look at this today.

[rationull]

I agree this is good for linking from the index. I've added some comments about what I think could be improved, but I'm not suggesting we should delay for this.

[rationull]

A few comments generally on module isolation, that I'll leave here:

One small point: think it would help to provide some examples to clarify what "kept separate from other parts of the runtime" means in practice.

Larger point: It seems to me that the overall story on module isolation is still meaningfully undefined. For instance:

1. What is the interaction between invoker/sandbox level dialect declaration and per-module (for modules evaluated in that sandbox)?
2. Is the main strategy/intent actually focused around binding limitations (careful dialect design and limiting mappings to forms that modify/expand bindings) or is the runtime-guards story just not fleshed out yet and so neither is its part of the overall strategy?
3. What is the story for cases where user-code includes defining (pure-Fusion) modules, and we want to allow cross-require among those modules without giving up restrictions on access to dangerous standard modules like java_new? I think the story here relies on as-yet-undefined per-repository controls, and so maybe this use case is just not well supported right now vs inline script eval style use cases.

Overall I'm wondering if we can add more clarity here around the relationship between the overall long term vision, the parts that are already concretely outlined or implements and which are not, and what specific usage patterns are well-supported now vs should be blocked/avoided until their dependent controls are implemented.