lotus_domino_hashes scanner speedup and fixes

- Record the FullName of the account and not the ShortName. The
  ShortName is not always allowed to be used for logging in to servers
  and is disabled by default post-Domino 6
  (http://www-01.ibm.com/support/docview.wss?uid=swg21218067).

  NOTE: One issue that has not been cleanly resolved here is that the
  FullName parameter is actually a list of names. Currently I do not
  process the FullName after retrieving it and store the list of
  usernames as the username. Thus an entry for the user 'Joe
  Schmoe/US/COMPANY; Joe Schmoe' is created. This isn't particularly
  clean or correct IMO but I'm not sure I like either of the other two
  options I can think of either:

  1) Split on the ; and store the first entry. Downside: loses an
     alternate account name that may be useful information.
  2) Split on the ; and store each entry as a separate credential.
     Downside: Many duplicates in the credential database. As the names
     are not necessarily easy to uniquify this could make reporting on
     the credentials more painful.
- Support retrieving entries via Readviewentries in larger batches than
  by default. Also actually process the Readviewentries response as a
  list of account IDs rather than just grabbing the first account ID
  each time. Together these two changes provide a significant speedup on
  large sites as it halves the total number of HTTP requests needed.
  I set the batch size at what I believe is a reasonable number (10000).
  Documentation I have seen says the largest possible Count value is
  65535 but I left it a bit lower to not put too much load in a single
  request. 10k accounts is probably about a 5MB XML response.
- Support restarting hash retrieval from a particular index in
  Readviewentries. This is very useful if you have say pulled 6000 of
  12000 password hashes when the server times out a connection.
- Make exception handling consistent throughout and handle all
  connection errors. If we fail partway through a site report the index
  we were requesting so that the user can set the index to resume from.

  NOTE: I'm new to ruby and I went with blanket rescues here
  because I couldn't find an authoritative list of exceptions that
  might result in the HTTP connection failing. As I went with 
  catch-alls I made the begin/rescue blocks as small as possible 
  around the send_request_raw calls but I'm open to better ways
  to do it. It is critical that failed HTTP connections be handled
  so that we know what account index we were on though. In
  dumping large databases the previous version would silently
  stop on a network error fooling the user into thinking the dump
  had completed successfully. We need to be able to reliably
  report there was a failure and where the failure occurred so 
  resuming dumps is possible.
- Support basic and form authentication using the same settings. Use the
  HTTP response code to figure out which route to go. Previously if
  you set NOTES_USER/NOTES_PASS these creds would not be used
  if the Domino server was configured to require basic auth. I thought
  this confusing so changed it around.
- Fix prints to report the correct protocol when using SSL.
- Check report_service's return value is valid before using.