Fix #3733: javalib FileChannel transfer* methods now honor Long counts

[LeeTibbert]

Fix #3733

Two javalib java.nio.channels.FileChannel methods, transferFrom and transferTo now more closely
follow the JVM specification by honoring counts which exceed Integer.MAX_VALUE.

They also more closely follow the specification in a number of ways, argument checking, zero transfers, etc.
Internally, the methods now buffer if the transfer count is greater than an internal limit.
That limit is currently 8192 or 8KB and is subject to change without notice or deprecation.

Two Linux only unit-test cases are provided which transfer more than Integer.MAX_VALUE bytes. These
cases are surprisingly fast and are enabled for CI. If CI execution time or cost becomes a
concern, they can be @Ignored and run manually.

A surprising macOS feature/quirk with reading more than a zero byte count from "/dev/zero' keeps these tests
from running there.

[LeeTibbert]

The one failing test is something new for multiarch

java.io.IOException: No space left on device

I examined the log file, but no hint of which device it was complaining about.
It could be related to this PR if there is something unique on that configuration
which has a problem writing to /dev/null. I could not look at the wreckage to
determine what might be breaking. Perhaps /tmp?

Let's see if the retry pixie visits overnight and what results then.
I'll study the log file more closely by the light of day.

All the other tests are quite Green. The build itself has been getting much
healthier. Wojciech, thank you for all of your effort fixing quirks; it is paying off,
increasing devo confidence, and saving devo time (other than the time you are putting in).

[WojciechMazur]

Looks good to me, I've seen the failure on Arm64 also in other PRs so it's unrelated. Probably it's due to our testing infra and running build in container.