Add initial support for variable length dnodes

This commit is a first attempt at supporting variable length dnodes. To
do this, a "dn_szsec" field was added to the current on-disk dnode_phys
structure. This field describes the size of the physical dnode on disk.
Rather than changing the size of the dnode_phys structure, 8 bits were
taken from the zero filled dn_pad2 field and allocated to the new
dn_szsec field.

To make use of the new variable length dnode feature, the "dnodesize"
dataset property was introduced. When a new object is allocated, this
property is used to set the size of that object's dnode. By default it
is set to 512 bytes, but that can be changed dynamically using the
normal mechanisms for changing dataset properties. For example, to start
using 1K dnodes for all new objects, run the following command:

    # zfs set dnodesize=1k tank/fish

As a result of the now variable length size of a dnode on disk, various
parts of the code had to be updated:

    * dnode_hold_impl's prototype was modified to take a "sectors"
      parameter. When the DNODE_MUST_BE_FREE flag is used, this
      parameter is used to ensure the "hole" at the specified object
      offset is large enough to hold the dnode being created.

      For example, consider a dnode meta object that has object 10 and 12
      allocated, but not 11. If a hold is taken on object 11 with flag
      DNODE_MUST_BE_FREE and sectors set to 2, we must fail. There is
      only a single 512b sector available at object offset 11 and we're
      requesting to hold a new dnode with size of 2 sectors. This 2
      sector large dnode cannot fit at object offset 11, so we fail.

      In addition, this new "sectors" parameter is used to ensure a
      dnode object does not span multiple dnode blocks. This is done to
      ensure a dnode's bonus buffer space must not span multiple blocks.

      In both of these cases, if a failure occurs, ENOSPC is returned.
      Keep in mind, these failure cases are only possible when using the
      DNODE_MUST_BE_FREE flag. If DNODE_MUST_BE_ALLOCATED, "sectors"
      *must* be set to 0 and there is externally visible change in
      behavior.

    * In dnode_next_offset_level, the code iterating through a block
      filled with dnodes had to be updated. Since the physical size of a
      dnode is no longer fixed, a simple array indexing scheme is no
      longer possible. Rather, we must use the current dnode's dn_szsec
      field to iterate to the next dnode in the block. This is to ensure
      we properly skip the current dnode's bonus area, and don't try
      interpreting it as a valid dnode.

    * dmu_object_next had to be modified internally to remove it's
      implied assumption that all dnodes are of size DNODE_SIZE.

    * dnode_allocate now takes a "sectors" parameter used to initialized
      the newly created dnode. Likewise, "impl" versions of
      dmu_object_alloc and dmu_object_claim were created to take a
      "dnodesize" parameter. "dnodesize" is in bytes, whereas "sectors"
      is in number of 512b sectors. This difference was done to try and
      limit the number of places in the code where bytes is converted in
      to 512b sectors.

Finally, the zdb command was updated to display a dnode's dn_szsec
field when the object is dumped under the "szsec" column.

Unfortunately, this work isn't finished. Some development items which
still need to be completed are:

    * This type of change needs dataset level feature flags which has
      yet to be implemented.

    * Backwards compatibility. How does this patch deal with a pool that
      was created without this new feature? It _should_ be able to
      handle the old format just fine, but I doubt the code handles this
      case just yet.

    * Policy surrounding the upgrade process of "old format" dnodes, as
      well as upgrade/downgrade process if the default dnode size is
      changed. For "new format" dnodes, if the default is changed,
      should we updated existing dnodes to obey this new size? Should
      "old format" be upgraded to the "new format" if nothing else
      dirties them?

    * I think there's a possible infinite loop in dmu_object_alloc if
      dnode_hold_impl continually returns an error. For example,
      dmu_object_alloc will call "hold" on object N. On error of "hold",
      it will call dmu_object_next on object N, which will in turn call
      "hold" on object N. If the hold fails again, it will loop around
      and repeat this process. If the hold never succeeds, N will never
      increment and I don't think the loop will ever exit. Verify/Fix.

I'm probably forgetting some other "TODO" items, but this'll suffice.

Signed-off-by: Prakash Surya <surya1@llnl.gov>