This patch extends the description of `FLOW.close` to include discussion
of the flow state when one side has called `FLOW.close` and the other
has not.

Hopefully this is not actually a change in intended meaning, as the
mirage tcp/ip stack already behavies this way: `FLOW.close` is
implemented by sending a `FIN` to the peer which terminates only one
side of the full-duplex connection. When the peer finishes transmitting
all of its data -- at some arbitrary later date -- it will also send a `FIN`
to close the remainder of the connection.

`FLOW.close` means I will not call `write` again, so the peer can
receive `Eof` once it has read all pending/buffered data. This patch
clarifies that, after calling `close`, I can still call `read` to
read data being written by the other side, until the other side also
calls `close`.

`FLOW.close` is a handshake with the peer: when the peer also calls
`FLOW.close`, both threads unblock and resources associated with the
connection can be freed.

Signed-off-by: David Scott <dave.scott@docker.com>

Clarify the meaning of `FLOW.close`

Minor readme fix

Prepare 2.7 release