Update exception handling strategy

Currently the very few existing application exceptions inherit from dk.netarkivet.common.exceptions.NetarkivetException which itself extend RuntimeException.
In my experience I have observed that is is generally a good programming practice to have a more evolved exception handling:

• first I would not use RuntimeExceptions unless we are sure the error is unrecoverable and even so I never use RuntimeExceptions in any production quality code for the reasons listed below
• provide a simple API for application exception that allows:

• distinction between application errors (i.e. errors that we know might happen during processing and that we want to precisely identify as such and potentially try recovering from) and unexpected errors (anything else)
• uniquely identify an application error
• provide additional information than stack trace
• automatically log any application error with support for internationalization
• associate a criticity level to an application error (i.e. is it worth continuing running the application when error X happens or is it recoverable)
  I am not especially fond of very complex exception handling but the simple fact of being able to precisely track the nature of an error and be sure it is logged without cluttering the code with catch/log statements is something I find crucial and do in nearly any Java program I write even the simplest ones.
  I'll be happy to discuss this when the opportunity arises.