libminixfs: allow non-pagesize-multiple FSes

The memory-mapped files implementation (mmap() etc.) is implemented with
the help of the filesystems using the in-VM FS cache. Filesystems tell it
about all cached blocks and their metadata. Metadata is: device offset and,
if any (and known), inode number and in-inode offset. VM can then map in
requested memory-mapped file blocks, and request them if necessary.

A limitation of this system is that filesystem block sizes that are not
a multiple of the VM system (and VM hardware) page size are not possible;
we can't map blocks in partially. (We can copy, but then the benefits of
mapping and sharing the physical pages is gone.) So until before this
commit various pieces of caching code assumed page size multiple
blocksizes. This isn't strictly necessary as long as mmap() needn't be
supported on that FS.

This change allows the in-FS cache code (libminixfs) to allocate any-sized
blocks, and will not interact with the VM cache for non-pagesize-multiple
blocks. In that case it will also signal requestors, by failing 'peek'
requests, that mmap() should not be supported on this FS. VM and VFS
will then gracefully fail all file-mapping mmap() calls, and exec() will
fall back to copying executable blocks instead of mmap()ping executables.

As a result, 3 diagnostics that signal file-mapped mmap()s failing
(hitherto an unusual occurence) are disabled, as ld.so does file-mapped
mmap()s to map in objects it needs. On FSes not supporting it this situation
is legitimate and shouldn't cause so much noise. ld.so will revert to its own
minix-specific allocate+copy style of starting executables if mmap()s fail.

Change-Id: Iecb1c8090f5e0be28da8f5181bb35084eb18f67b
testmfs, testisofs: MFS format, ISO functionality

testmfs: catch MFS format changes

This test tests mkfs.mfs will generate the same FS image given the same
input files. mkproto creates a proto file (normalizing directory entry
order). The assumption is that a change in the output flags a tacit
change in FS format, and that a FS format change will cause the image
to change.

        . Changes to mkfs.mfs that innocently change the format can
          change the sha1 output in the script along with it.
        . The assumption is that corresponding versions of mkfs.mfs and
          MFS will always work together; otherwise a lot breaks (ramdisk etc.)
        . Therefore, as long as a generated FS image stays the same with the
          same input now, incompatible MFS changes will still be flagged,
          even if they work together with the current mkfs.mfs.

testisofs: test ISO filesystem

        . to test isofs: prepare an ISO FS image using writeisofs, copy it
          to a RAM device, mount it using the iso9660fs server, compare the
          SHA1 contents of the files on the ISO with the inputs.
        . use su to run certain commands in the script as root

run script: run shell script tests

	. they are installed without .sh so should be
	  searched for as such
	. add diagnostic when tests are skipped

Change-Id: I30daff58e1e43903dacf3c99996a4a0e7d819b6b