Revert "Revert "Allow Java byte arrays to be directly encoded for byte sequence types.""

This reverts commit 20b03e65af207d7cc73b0d0e11229d0897c4c9b4.

Put #69 back, haha.
Reconcile #69 with the encoding fast path.

Treating byte arrays as decoded values of unframed byte sequence types
does not actually conflict with using an encoding "fast path".

The trick is to realize that the fast path only applies to calls to
`#encode`, since the optimization can only apply when we're allowed to
return our own parameter.  It would be moot if we had to make a copy,
which is exactly what `#encode_to_stream` has to do.

If control reaches `#encode_to_stream`, then in essence we've already
given up on the fast path.  As such we can still require that the
incoming values be "decoded", and that we encode them.

Since raws and byte tuples have byte-identical encoded and decoded
forms, it's harmless to let them skip the array allocation by letting
in byte arrays directly.

Since a bytes does not encode as itself, we still require the
encoding step to take place.  To signal this, bytes types still reject
incoming byte arrays.
Merge pull request #74 from seomoz/phs/fast-path-encoding-for-named-and-packed-types

Phs/Put pull #69 back