Push flow control down into Endpoint.Stream.

This is part of making a functioning server, but it also somewhat
simplifies the Client interface for initiating a stream.

Before, a Stream contained

 - a data producer, for outgoing data
 - a header consumer, for receiving incoming headers
 - a data consumer, for receiving incoming data

Incoming data and headers were fed to the header consumer and
data consumer by the reader thread itself. This had two problems:

1. nothing prevented the header consumer and the data consumer
   from performing expensive or blocking computations, which is
   not a good idea for something invoked by the reader thread

2. it put the burden of flow control partly on the the data
   consumer, since it had to decide what the delta window size
   should be.

(2) introduced another wrinkle. Since the delta window size might
be zero, we needed the Endpoint.sendWindowUpdate function so that
the app layer could send a WINDOW_UPDATE manually.

The changes here aim to eliminate this complexity by putting all
flow control considerations into the Endpoint module. In the
process, Endpoint has become a bit more complicated, but Client
is now simpler, and the interface for fetching response data is
easier to use, as witnessed by some changes in the SGet program.

The data producer, header consumer, and data consumer are now
gone from the Stream type. Instead, EndPoint.addStream takes
an optional *content* producer, where content encompasses header
blocks, data chunks, and a flag that indicates whether this is
the last content on this side of the stream. See the new
StreamContent type. In StreamOptions, the corresponding fields
have also been removed, and in their place is simply an optional
content producer. When the content producer is 'Nothing', the
FIN flag is set on the SYN_STREAM frame that opens the connection.

In the place of these original fields, Stream now has a quantity
semaphore and a BoundedBuffer. The quantity semaphore is used to
enforce flow control on outgoing content. The BoundedBuffer is
used to temporarily hold incoming content, and allows us to enforce
flow control on the incoming side of the stream.

This required changes in four places:

- the default incoming frame handlers in Endpoint need to
  handle incoming headers and data by putting content into
  the BoundedBuffer for the involved stream

- the default frame handlers also handle WINDOW_UPDATE frames
  by signalling available space on the semaphore for the involved
  stream

- the Endpoint.addStream function now has more work to do. If it
  is given a content producer, it launches a thread that pulls
  data from the producer, waits on the quantity semaphore, and
  queues the necessary frames to the remote endpoint. It also
  returns a response producer, an IO action that takes the
  next available content from the BoundedBuffer.

- the Client.initiateStream function is now simplified a bit.
  Since the content producer is optional, it no longer needs
  to try reading the first chunk of data to see whether to
  set the FIN flag on the SYN_STREAM frame. It also returns
  the response producer returned by Endpoint.addStream.

The Client module no longer needs input frame handlers: all the
necessary stuff is now done in Endpoint itself. Consequently,
the handlers are now gone, though I've kept
'stdClientInputFrameHandlers' for the time being, just as another
name for the handlers in Endpoint.

For the application layer, the interface for receiving the
response content is now easier to use. Before, SGet had to have
a pair of MVars to signal the end of headers and the end of
data. Now, it simply has a loop that draws content from the
response.

There are still several rough edges here. In particular

- we don't make sure that data frames sent to the remote
  endpoint are small enough. i.e. that they are no bigger
  than the agreed-upon window size

- if we can't buffer an incoming data frame, it means that
  the remote endpoint is not respecting flow control, but
  we do not signal the necessary error

- if there is an exception in the thread that sends content
  to the remote endpoint, we don't handle it gracefully.
  There should be a RST_STREAM with an indication of an
  internal error, and a graceful shutdown of the stream.
  If there error is in the header compression, we in fact
  need to tear down the entire connection.

- there is repeated code in Endpoint's incoming frame handlers
  that ought to be put in a function.

And there are probably many other problems that I have yet
to find. But this commit is involved enough that I'd like to
check it in before fixing the other problems.

Note that at this point all the code compiles and SGet is able
to fetch resources from the 'flip' server and www.google.ca.
Add the -W flag to the GHC_FLAGS in the Makefile.

I noticed some unnecessary imports in SGet in the last commit, but
I wasn't using -W to find them. Add the flag.
Remove remaining unnecessary imports in the sample programs.

Adding -W to the compiler flags in the Makefile revealed that the
SPing, tls-server and tls-client programs had unnecessary imports.
Remove them.