firmware(9) revision

Over the past days i have discussed with a few people (in Bcc) about
issues in firmware(9) that i would like to fix and possibly MFC.
I have prepared a revision version of the code at

	http://info.iet.unipi.it/~luigi/FreeBSD/firmware/

and would appreciate a review. If you see a discrepancy between
the comments and the code, trust the comments.

My main goal when i started this work was to fix some bugs
related to the automatic unloading of firmware images, i.e.:

- there is a potential race condition in the automatic unloading
  of modules, when [image] registry entries could be reused while
  the firmware_thread releases the lock to unload the container
  module; (affects HEAD and probably RELENG_6 as well)

- incorrect handling of unload requests for images loaded
  from the bootloader (RELENG_6).

(RELENG_6 might have more problems as the cleanup done to the code in
HEAD has not been merged yet; but it is pointless to enter into details).

While working on the code, more things came up, e.g.  the handling
of errors in unloading a module is unclear at best (and possibly
buggy); the semantics of FIRMWARE_UNLOAD needs to be explained
better; also, one could get the chance to cleanup the API
(reducing the amount of internal information exposed to clients,
and also putting const qualifiers on some arguments).

Clearly, the API change in RELENG_6 needs to be carefully evaluated;
on the other hand, the api change is limited to adding const
qualifiers to the arguments, and removing some fields from a
structure, as below:

 struct firmware {
 	const char	*name;		/* system-wide name */
 	const void	*data;		/* location of image */
 	size_t		 datasize;	/* size of image in bytes */
 	unsigned int	 version;	/* version of the image */
-	int		 refcnt;	/* held references */
-	struct firmware *parent;	/* not null if a subimage */
-	linker_file_t	 file;		/* loadable module */
-	int		 flags;		/* FIRMWAREFLAG_ flags */
 };

and clients are not supposed to touch or even look at such fields.
So in practice there should be full compatibility at the binary level.

	cheers
	luigi