std.http: a TLS server can take its certificate and key as PEM text, not only file paths #3362

http.server_set_tls(server, cert_path, key_path) takes file paths only, so a program that has its certificate and private key in memory must write the key to disk first. servirtium-vcr's HTTPS listener is built on it, and a .NET user of servirtium-vcr flagged the private key it has to write to %TEMP% in their tests as a security-review item.

Today. http_server_set_tls_raw (std/net/aether_http_server.c) stores the two paths. The OpenSSL backend loads them into an SSL_CTX at once; the pure-Aether backend keeps the paths and pure_tls_server_accept (std/cryptography/tls13_server/module.ae) reads both with fs.read on every connection, then parses the PEM text.

Wanted.

err = http.server_set_tls_pem(server, cert_pem, key_pem)   // "" or the reason

• Same contract as server_set_tls: "" on success, else why not.
• Both backends. OpenSSL loads the chain and key from memory BIOs. The pure backend parses the chain and key once, at set time, and the accept path uses the parsed form instead of reading files per connection (which server_set_tls could then share).
• The same set-time checks std.http: the pure-Aether TLS server never checks its certificate and key at server_set_tls (every handshake then fails silently) #3328 adds to server_set_tls (a malformed chain, an unusable key, a key that does not match the leaf) apply here, with the same messages.
• The no-networking stub returns its usual "unavailable" string.
• The key text is not copied anywhere it can outlive the server: freed (and cleared) when the server is freed.

Sequencing. #3328 and #3326 (Nic, in #3334) rewrite the same set_tls and accept code, so this lands on top of them.

Once it ships, servirtium-vcr adds vcr_embed_set_tls_pem and a .NET TlsFromPem(cert, key) over it.