Hello,
this PR aims to tackle one problem I had: streaming the output of a program while it is running over HTTP, similarly to the Github/GitLab CI "live" screens.
In fact, the goal is to perform a request to the server with cURL inside a gitlab-ci job, and see the output unfolds as the program is executed:

              web browser
----------    ------------> -------------------
| CLIENT |                  |  GitLab CI job  |
----------   <------------  -------------------
               streams the     |              ∧
                  output       |              |
                               | executes     | prints the
                               |              | output
                               |              | "live"
                               ∨              |
                             -------------------
                             |       cURL      |
                             -------------------
                              |               ∧
                              |               | streaming
                              | HTTP          | (chunked
                              | query         | transfer)
                              |               | of stdin
                              |               | and stdout
                  spawns      ∨               |
-----------  <------------   --------------------
| program |                  | tiny-http server |
-----------   ------------>  --------------------
               sends stdout
               and stdin in
                 a pipe

Without this patch, the program executes in its entirety, and the output is sent all at once
once the pipe where the program writes its output is closed.

To achieve that goal, I submit two "sub-features":

• The ability to disable buffering inside Response objects with the Response::with_buffered method.
  Enabling this will force the transfer encoding to be TransferEncoding::Chunked and will ask the
  chunks encoder to flush to its underlying writer on every write.
• To get "instantaneous" write, disabling buffering in the chunks encoder is not enough, as the underlying
  writer returned when calling Server::recv() (ClientConnection.sink) is in fact a BufWriter wrapping
  the "real" output. The buffered_writer option in ServerConfig, when set to false while instantiating
  a new server, omits the BufWriter to write to the TcpStream withotu any buffering. The cost of that
  abstraction is that ClientConnection.sink now boxes the writer to be able to choose between
  BufWriter<RefinedTcpStream> or RefinedTcpStream dynamically, which means there is now one additional
  pointer deference. I do however expect the performance impact to be small as this pointer is then stored
  in an Arc<Mutex<>>, and I think locking/unlocking the mutex should be more costly that deferencing the
  pointer.

I expect this to decrease performance when sending big files, which is why these two sub-features are disabled
by default, and must explicitly be opted-in (by calling the with_buffered method for the first, and by
instanciating the server with the buffered_writer setting for the second).

Also note that the current iteration of this work breaks the current ABI, as it updates ServerConfig to
add the buffered_writer option, and ServerConfig was already exposed through the Server::new function.