Add timeouts to response handling

[Alch-Emi]

This is a very preliminary attempt at handling #9.

From the docs:

Set the timeout on incoming requests

Note that this timeout is applied twice, once for the delivery of the request, and once for sending the client's response. This means that for a 1 second timeout, the client will have 1 second to complete the TLS handshake and deliver a request header, then your API will have as much time as it needs to handle the request, before the client has another second to receive the response.

If you would like a timeout for your code itself, please use tokio::time::Timeout to implement it internally.

The default timeout is 1 second.

It's worth noting that this leaves the questions from the original issue pretty unaddressed, specifically with how they should be worked into the API. In this PR, timeouts are set using the Builder for the Server, with no callbacks that might allow a client to handle them. I'm happy to write such a handler, but I'm not sure how best to go about it, or even what the usecases might be. What sort of things do you think a user would want access to when handling a timeout?

Also, I'm not really a security expert, so if this is not a safe enough timeout handling strategy, please let me know

---

This change is 

[panicbit]

Thanks! I'll review this one in ~10 hours ⌚ 👀

[panicbit]

[panicbit]

Turns out there's a reason for the existence of the HEAD method in http. Timeouts in Gemini are kinda tricky:

In this picture the request times out because the client is asking the user how to open the file.

[panicbit]

I guess this could be fixed by a different client behaviour, but all of this is very underspecified.