Due to continuing issues with VOP_READ/VOP_WRITE ops being called without

Due to continuing issues with VOP_READ/VOP_WRITE ops being called without
a VOP_OPEN, particularly by NFS, redo the way VM objects are associated
with vnodes.

* The size of the object is now passed to vinitvmio().  vinitvmio() no
  longer calls VOP_GETATTR().

* Instead of trying to call vinitvmio() conditionally in various places,
  we now call it unconditionally when a vnode is instantiated if
  the filesystem at any time in the future intends to use the buffer
  cache to access that vnode's dataspace.

* Specfs 'disk' devices are an exception.  Since we cannot safely do I/O
  on such vnodes if they have not been VOP_OPEN()'ed anyhow, the VM objects
  for those vnodes are still only associated on open.

The performance impact is limited to the case where large numbers of vnodes
are being created and destroyed.  This case only occurs when a large
directory topology (number of files > kernel's vnode cache) is traversed
and all related inodes are cached by the system.  Being a pure-cpu case
the slight loss of performance due to the VM object allocations is
not really a big dael.