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 figured we might be philosophically at odds here.

**TL;DR** IMO returning the struct pointer keeps the "implements interface" relation implicit as the language was intended by the language designers.

Specifically, I prefer this style because returning the struct pointer from the constructor gives you more freedom with the the API in the future. If the you decide in the future that the writer types in this package should implement a new method, say "PadTo(multipleof int64)", then it allows users to access that method without performing a type assertion.

You do see this pattern in the standard library (even for types intended to implement a specific interface). I don't have an example ready off-hand though.

I don't think you lose any generality by returning a concrete type (a struct pointer) vs an interface. That's because for these types there is no (idiomatic) way to implement the same functionality without structs. (you could probably implement the Writer, though not the BufferedWriter, with closures; but hopefully we both agree that idea is wrong).

Lastly, I don't think the minor inconsistency with the two other functions in the API is a big deal. That's subjective though.