Make fallocate/posix_fallocate more configurable.

When opening a file handle, add file-handle variables to note if
fallocate/posix_fallocate calls are available and if they require
locking.

Also, fallocate/posix_fallocate are known to fail at run-time based on
the underlying filesystem type. In that case, always return ENOTSUP from
fallocate/posix_fallocate, resetting the file-handle information and
falling back to ftruncate in the caller.

Remove the implementation of __wt_fallocate() using ftruncate, we may
have to re-acquire a lock when switching from a failed fallocate() call
to a ftruncate() call, when extending the file from the block manager,
so the caller has to do that work itself.

Reference #1267.
Revert POSIX OS changes from c5b71e5, reference #1254: that commit
changed ftruncate calls on file handles where the file was also mapped
(that is, a WiredTiger checkpoint was open in the object), to return
EBUSY instead of doing the truncate.

We use ftruncate() to extend files when fallocate/posix_fallocate are
not available or when running on filesystems that don't support them
(for example, ext3). I missed that use of ftruncate in the above commit,
so note the above commit wasn't complete and we could call ftruncate on
files where the file was also mapped into memory.

I'm not willing to lock out file extension if a file is mapped.  While
there are known problems in combining file mapping and ftruncate on
historic Linux systems, I don't know of any problems on current systems,
so I'm removing this restriction until we see a failure.

Reference #1267.
Merge branch 'develop' into fallocate-restructure
Merge pull request #1273 from wiredtiger/fallocate-restructure

Fallocate restructure