Change mechanism to retrieve start and end date for analysis

- We need the start and end date for limiting the history for the
  git blame analysis

- In the old approach there is a case where no cmt list exists
  and then the retrieval fails, it also wastefully looped through
  the whole list of commits

- We now retrieve the dates immediately after finding and sorting
  the dates for all commits and thus avoid looping though the
  entire commit list again and simultaneously fixing the emtpy
  commit list issue

Signed-off-by: Mitchell Joblin <mitchell.joblin.ext@siemens.com>
Fix case where ml analysis period is subset of VCS analysis periods

- the mailing list analysis periods may not always include
  the analysis periods for the version control system

- now we check for the case where the period falls outside
  the mailing list analysis range ignore the periods rather
  than fail completely

Signed-off-by: Mitchell Joblin <mitchell.joblin.ext@siemens.com>
Add precondition check for author of e-mail

- More defensive programming directly after loading the corpus
  to avoid failures in later analysis stages

- There are a variety of ways the author can be formatted, however
  the id service will fail if the author is not formatted according
  to the "name <email@something.com>" convention

- We now check for a many different possible cases such as
  name someone at gmail.com
  name someone@gmail.com
  someone@gmail.com name
  <someone@gmail.com> name
  name

- For each case we try to normalize it to the id service's convention

- If no name is present we assign "unknown" and if no email is present
  we create one by appending the name to "could.not.resolve@"

Signed-off-by: Mitchell Joblin <mitchell.joblin.ext@siemens.com>
The ts analysis requires at least 3 revisions

- With less than 3 revisions the analysis fails

- Check this requirement and log error if not satisfied

Signed-off-by: Mitchell Joblin <mitchell.joblin.ext@siemens.com>
Bug Fix: "if" instead of "elif" causing incorrect exception raising

- In the case of a deadlock error the 1213 exception is thrown and
  caught but the following if block for handling server connection loss
  evaluates to false and the else block is executed and raises the
  exception

- The result is every deadlock error ends up terminating execution
  because the exception is uncaught after being raised

Signed-off-by: Mitchell Joblin <mitchell.joblin.ext@siemens.com>