preliminary path for MappedByteBuffer and java.nio changes

[Per Bothner]

I've been working on implementing java.nio.MappedByteBuffer
and related (I hope) improvements to java.nio.  A patch is
(temporaily) at ftp://bothner.com/pub/libjava.patch . This
is a patch for GCJ, relative to the trunk.

See the "preliminary java.nio with MappedByteBuffer" on the
address@hidden mailing list.

The basic idea is as discussed in previous emails:
FileDescriptor isn't much used any more and contains
no native methods; instead FileDescriptorImpl contains
most of the native code for working with files.
Also, note how the natFileChannelImpl.cc #includes
natFileChannel{Posix,Win32,Ecos}.cc depending on
#defines in platform.h, without any symlinks.

MappedByteWork works (at least for read-only mapping)
on both Posix (Fedora Linux) and Win32 (Windows Me).

The ByteBufferHelper methods now take an explicit
ByteOrder parameter.  This is needed because we're
supposed to use the ByteOrder of a ByteBuffer when
the various View classes are created, not whatever
the current ByteOrder of the underlying ByteBuffer.
Also, the DirectByteBuffer getXxx methods now use
ByteBufferHelper.
--
        --Per Bothner
address@hidden   http://per.bothner.com/