Datahandle test improvements and Endianness fixes

[gab1one]

The coverage of DataHandle by DataHandleTest was not sufficient, a lot of methods where untested. This PR greatly extends the test coverage and fixes some discovered bugs.

[ctrueden]

Thanks for working on this! I think it's great. There is just the performance concern I mentioned. Can you make a byte[8] upfront and just reuse it in all the places you need a small byte array?

[ctrueden]

This will destroy performance. We cannot allocate a new byte array with every short read. You could use an instance field buffer of sufficient size to avoid the issue.

[gab1one]

How can we cache this in the interface though? Should we require all DataHandle implementations to provide a buffer array which is used for conversions? Should be easy to put into the AbstractDataHandle

[ctrueden]

Same: performance will tank. Need a small reusable byte[] as instance field. This should be OK, since these methods are already not thread-safe.

[ctrueden]

Need to use a reusable buffer.

[gab1one]

@ctrueden, I addressed your performance concern in 7b7e03b
I am not sure I like this solution though, it might be better to just push the affected methods into AbstractDataHandle and not expose the conversionBuffer in the interface.

[ctrueden]

@gab1one I considered different solutions to address the issue of conversionBuffer() as public API in the interface.

One idea I had was to use a static ThreadLocal<byte[]> in a utility class, to give back a unique byte[] per thread. I benchmarked it, and the performance is equivalent to your direct field storing the byte[] per instance of DataHandle.

Then I thought: where will this utility class live? What will it be called? It is pretty specialized, always returning a byte[8]. It could be generalized, but maybe YAGNI applies here. I figured we want this to be an internal implementation detail, so the utility class itself should maybe be package-protected.

But then I wondered: is it ever useful to be able to override the conversion buffer access? I am torn. There might be cases where it is helpful downstream; I don't know. (But this also might be a case of YAGNI.)

I am definitely not eager to move so many default method implementations in the abstract layer, since it makes implementing the interface directly much more complicated, even though as you point out it would certainly have better encapsulation regarding this issue.

In the absence of a clearly superior alternative, I'm going to merge this as-is with the conversionBuffer() method exposed in the public API.

By the way, in my investigations, I was curious whether interfaces can have inner classes, and indeed they can! But they are always public static. (I was thinking this is a way to embed static fields in an interface: nest them inside an inner class as static fields of that class. But then the interface has a weird inner class exposed to the world, which is still not very nice.)