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
I don't think it's the savings of words that are important, it's the idea that making the type impossible to use incorrectly avoids the necessity for documentation in the first place.  This doesn't mean you shouldn't have documentation, it just means that things are obvious.

This type has no exported variables and only provides 3 instance methods, right now.  It seems like a *perfect* case for this.

IMO, the real problem is the inconsistency with how to create and use this type as written.  Is one allowed to just use a literal, like `&BufferedWriter{}`?  Not currently, because it requires some setup.  We could fix this and allow that, but there would still be an inconsistency, IMO, with having the `New` method.  This is resolved if the type itself isn't exported.

It's about API footprint, really, and the smaller that footprint the easier it is to grow and maintain.

If the API starts by exporting just an interface, (potential) future additions to the API are not backwards incompatible (no code breaks), removals are, which we wouldn't do.

Since there are conventions for both, we can find examples in the standard library to support or conflict with our opinions, which is all this discussion is at this point.

Given that the rest of this API follows this pattern, I would prefer this do the same.