Change Close semantics to flushing the last buffer and waiting

Previously, it was possible for logplexc to lose one buffer's worth of
logs when running .Close().  While it would wait for existing
outstanding HTTP requests, it would not make any attempt to flush the
buffer being accumulated to the network.  Now it does.

History:

At one time, these semantics were considered a feature, making the
then-asynchronous version of .Close() clean up as fast as possible.

However, for various reasons .Close() was made synchronous (thus, the
caller might expect that .Close can take some time) and waits for
outstanding HTTP requests to finish.

Then, it was witnessed that these "abort as fast as possible"
semantics resulted in predictable dropping of logs from short-lived
Postgres connections.  So, given that .Close() could take a while to
clean up anyway, it seemed prudent to change the semantics to flush
the accumulated buffer while closing down.

As it turns out, this unification of semantics allows removal of
double-bookkeeping to simultaneously support aborting the buffered
data while allowing in-flight requests to finish.  No more WaitGroup
nor finalization channel are necessary in particular.