simple BufferedWriter type

```go
func (w *BufferedWriter) Close() error

func (w *BufferedWriter) Flush() error

func (w *BufferedWriter) Write(p []byte) (int, error)
```

- BufferedWriter writes blocks when flushed or MaxBlockSize bytes
  accumulate.

- Add tests and benchmarks corresponding to Writer's.

- Rewrite existing tests to demonstrate buffering misalignment.
  bytes.Reader/.Buffer types have optimizations which help in io.Copy.

Closes #3
At this point I just want to make clear that there is no existing "WriteFlushCloser" interface in the standard library. One would need to be defined in the package. Not an engineering hurdle or anything but I don't think it's ideal to define that particular interface (with those methods) in a package called "snappystream". That is, some of the obviousness is lost not being a standard interface (leaving you with little undocumented obviousness than the method names themselves... which are fairly obvious in this case). Moving on...

The fact that there are no exported fields in the struct is ephemeral. In the future is most certainly the potential for public fields; specifically, buffer tuning parameters (see snzip). I see no reason why these shouldn't be modifiable after construction (since the user is handling synchronization themselves as you suggested). 

I disagree with the idea that any struct which cannot be used as a zero value should be left unexported. That is far too restrictive. I liken it to saying pointer types shouldn't define any methods which do not explicitly handle nil receivers. Handling nil receivers is a good practice some (or even most) of the time when one of the function/method's return values is an error. But the fact is that, most of the time, no one does this. Afaik it's not even considered a bad practice. At some point you have to concede to convention and the belief/hope that the programmer is not completely incapable doing their job adequately and reading some amount of documentation for the libraries they are paid to choose and make proper use of. If I see structs with unexported fields (as is the case here) or, for some reason, a New* method that constructs them I take note and act accordingly.

I am very much in disagreement with the implied simplification that it's all about API footprint (and further how that implies easy growth and maintainability). You need to be able to evolve the API without stacking on interface after interface ("we have a WriteFlushCloser. oh, but now we have this Reset method that we want to use (see encoding/gzip). ok let's make a WriteResetFlushCloser. oh wait Writer can use that method too. Lets make a WriteReseter."). The backwards compatibility curse is bloating your API and you need to you type assertions which raise the runtime's anxiety levels. IMO structs are the best way in this situation to optimize performance, API quality, and cognitive load (not necessary prioritized in that order).