Bug 3875: bad mimeLoadIconFile error handling

Bug 3875: bad mimeLoadIconFile error handling

Improve the MimeIcon reliability when filesystem I/O errors or others
cause the icon data to not be loadable.

The loading process is re-worked to guarantee that once the
MimeIon::created callback occurs it will result in a valid StoreEntry in
the cache representing the wanted icon.

* If the image can be loaded without any issues it will be placed in
the cache as a 200 response.

* If errors prevent the image being loaded or necessary parameters
(size and mtime) being known a 204 object will be placed into the cache.

NP: There is no clear agreement on 204 being 'the best' status for this
case. 500 Internal Error is also appropriate. I have use 204 since:

* the bug is not in the clients request (eliminating 400, 404, etc),
* a 500 would be revealing details about server internals unnecessarily
   often and incur extra complexity creating the error page.
* 204 also avoids needing to send Content-Length, Cache-Control header
  and body object (bandwidth saving over 500 status).

NP: This started with just correcting the errno usage, but other bugs
promptly started appearing once I got to seriously testing this load
process. So far it fixes:
* several assertions resulting from StoreEntry being left invalid in
  cache limbo beween created hash entries and valid mem_obj data.
* repeated attempts on startup to load absent icons files which dont
  exist in the filesystem.
* buffer overfow on misconfigured or corrupt mime.conf file entries
* incorrect debugs messages about file I/O errors
* large error pages delivered when icons not installed (when it does
  not assert from the StoreEntry)