Add byte slice accessor to Go code

[bmharper]

A few weeks ago I added CreateByteVector, which provided an efficient means of creating a [ubyte] vector when creating a flatbuffer object in Go code.

This commit adds the reciprocal function, which is a [ubyte] getter, which returns a byte slice (type []byte). This adds a special getter with the signature
func (rcv* Object) FieldBytes() []byte { ... }

If a [ubyte] is the de-facto way in which one stores a buffer inside a Flatbuffer object, then I believe this is worth supporting.

[rw]

Thanks, LGTM. FWIW, I'm considering changing all string accessors to return byte slices, since strings always cause an allocation.

[bmharper]

Wow, I didn't know that. However, surely one would want the flatbuffer type "string" to be represented by the idiomatic utf-8 string type of the language? If one has to cast the byte slice to a string before using it, then would you even be winning anything? I found this issue golang/go#6714 which discusses []byte -> string cast allocations.

When doing this work, I was wondering whether I shouldn't just use "string" to represent an arbitrary buffer, but (without actually doing the homework) I was worried that some language such as Java would end up representing "string" as UTF16, which would be very painful.

[rw]

Given that the allocation issue has been outstanding for years, I doubt they will be fixing it soon. Even if they do, we'll have to wait (at least) for the 1.5 release.

We should bite the bullet and just return byte slices pointing directly into the FlatBuffer data, and require the caller to copy or cast it, as they wish.

[ghost]

While FlatBuffers typically chooses efficiency over usability if the two can't be united, having to cast all the time doesn't sound great either. Another option is to generate accessors for both?

Meanwhile let me get this change in.

[ghost]

cherry-picked into 8b99bf6