block: Auto-generate node_names for each BDS entry

Currently, node_name is only filled in when done so explicitly by the
user.  If no node_name is specified, then the node name field is not
populated.

If node_names are automatically generated when not specified, that means
that all block job operations can be done by reference to the unique
node_name field.  This eliminates ambiguity in filename pathing
(relative filenames, or fie descriptors, symlinks, mounts, etc..) that
qemu currently needs to deal with.

If a node name is specified, then it will not be automatically
generated for that BDS entry.

If it is automatically generated, it will be prefaced with "__qemu##",
followed by 8 characters of a unique number, followed by 8 random
ASCII characters in the range of 'A-Z'.  Some sample generated node-name
strings:
    __qemu##00000000IAIYNXXR
    __qemu##00000002METXTRBQ
    __qemu##00000001FMBORDWG

The prefix is to aid in identification that this is a qemu-generated
string, the numeric portion is to guarantee uniqueness in a given
qemu session, and the random characters are to further avoid any
accidental collisions with user-specified node-names.
block: add helper function to determine if a BDS is in a chain

This is a small helper function, to determine if 'base' is in the
chain of BlockDriverState 'top'.  It returns true if it is in the chain,
and false otherwise.

If either argument is NULL, it will also return false.
block: Accept node-name arguments for block-commit

This modifies the block operation block-commit so that it will
accept node-name arguments for either 'top' or 'base' BDS.

This means that:

1.) Both "top" and "base" are completely optional.  Previous, "base"
    was optional, but "top" was required.

2.) If "top" is not specified, it defaults to the active layer

3.) "top" and "top-node-name" are mutually exclusive (enforced)

4.) "base" and "base-node-name" are mutually exclusive (enforced)

The preferred and recommended method now of using block-commit
is to specify the BDS to operate on via their node-name arguments.

This also adds an explicit check that base_bs is in the chain of
top_bs, because if they are referenced by their unique node-name
arguments, the discovery process does not intrinsically verify
they are in the same chain.
block: extend block-commit to accept a string for the backing file

On some image chains, QEMU may not always be able to resolve the
filenames properly, when updating the backing file of an image
after a block commit.

For instance, certain relative pathnames may fail, or drives may
have been specified originally by file descriptor (e.g. /dev/fd/???),
or a relative protocol pathname may have been used.

In these instances, QEMU may lack the information to be able to make
the correct choice, but the user or management layer most likely does
have that knowledge.

By extending the block-commit, the user is able to change the backing
file of the overlay image as part of the block-commit operation.

This allows the change to be 'safe', in the sense that if the attempt
to write the backing file image metadata fails, then the block-commit
operation returns failure.

If the commit is from the active layer, then specifying the backing
file string will be treated as an error.

If a backing file string is not specified in the command, the backing
file string to use is determine as it was before.