Rewrite chunks of Nick's original draft to try and get a better through-line

[njsmith]

Almost certainly needs a good editing pass at least, but since Nick
said he's going to work on this today then I'll put this up for him to
take whatever he wants out of :-)

@ncoghlan @dstufft

[the-knights-who-say-ni]

Hello, and thanks for your contribution!

Unfortunately we couldn't find an account corresponding
to your GitHub username at bugs.python.org (b.p.o).
If you don't already have an account at b.p.o, please
create one and make sure to
add your GitHub username. If you do already have an account at b.p.o then
please go there and under "Your Details" add your GitHub username.

And in case you haven't already, please make sure to sign the
PSF contributor agreement
(CLA); we can't legally look at your contribution until you have signed the
CLA.

Once you have done everything that's needed, please reply here and someone will
verify everything is in order.

[njsmith]

@the-knights-who-say-ni: Added my github username to my bugs.python.org profile. I have signed the CLA.

(Are people really required to sign the CLA before submitting PEPs?)

[ncoghlan]

@njsmith Yep - Van Lindberg (the PSF's lawyer) asked Brett to implement it that way, and given that PEPs often cover API design, and US law currently considers API design copyrightable, it seems like a reasonable precaution.

[ncoghlan]

Combined Nathaniel's additions with my changes in #23.

I'll note one difference is that I've scrupulously avoided the terms "secure" and "non-secure" as they don't actually make sense without a documented threat model to judge them against (and the threat models of the Linux kernel, the CPython runtime and any given Python script or application are all going to be different).

The replacement terms are a bit more of a mouthful, but help avoiding getting hung up on arguments about what "secure" means by focusing on the relevant characteristics instead:

• "security sensitive" and "non-security sensitive" operations and use cases
• "reliably unpredictable" and "potentially predictable" data