This makes the server more compliant with what is to be expected and
prevents routes from matching when a wrong scheme is given (such as
https://).

It is not perfect yet, as abusing the route matching function for such
an important property is probably not the best. We also want to
implement other request-sanity-checks (such as port numbers being
given), which would also be better done at a different place.

However, we also don't want to prevent Cana from being used to implement
Gemini proxy servers, so a flag in GeminiServer would probably be nice
("extended URI checks").

Yet - on the completely other hand - allowing that much freedom also
means weird interactions (such as a default vhost, certificate issues,
...), so it is unclear how far we want to go.

This is already mandated by the TLS spec, but has been made explicit as
well for Gemini servers[1]:

> As per RFCs 5246 and 8446, Gemini servers MUST send a TLS
> `close_notify` prior to closing the connection after sending a
> complete response. This is essential to disambiguate completed
> responses from responses closed prematurely due to network error or
> attack.

We want to be well-behaved, therefore we now send close_notify properly
after writing a response.

You can verify this easily using [2].

[1] https://gemini.circumlunar.space/docs/specification.html
[2] https://portal.mozz.us/

This is more conforming to other CGI environments, see for example [1]
and [2].

This also allows us to easily add more fields in the future, for example
to pass the remote address, the TLS certificate, the server version, ...

[1]: https://en.wikipedia.org/wiki/Common_Gateway_Interface#Example
[2]: https://sr.ht/~int80h/gemserv/

So far, the tests are still pretty pointless, but the infrastructure to
build better tests is there now.

A static file handler that lists directory contents can be set up as
follows now:

  <staticfiles path="gmdocs">
    <indices />
  </staticfiles>

An argument could be made to have it as an attribute instead (<...
indices="true"  />), but we will have to see how this works out.

This allows Cana to do directory listings. Since we expect more settings
to become available for the static file handler (such as ExecCGI or
IndexFile), a struct holding the parameters has been introduced already.

1. This function used 'fail', which is rather bad - now it returns
   'Either'

2. The function was still hardwired to the specific filenames of the
   first prototypes.

This alleviates the need to define the server in Haskell and
re-compile the binary every time something in the configuration changes.