Change how git blame is called on the file revisions

- When using dates to specify the revision range we need a
  different approach than when specifying a commit range

- We now decouple how we find the edited files from how the revision
  range is specified and instead use information from the commits we
  wish to analysis which may be specified using dates or revision ranges

- Since commit dates are not necessarily in chronological order, if dates
  are used to specify an analysis window, we need to call git blame
  on the lastest revision within the date range and not the revision
  that specifies the end of the analysis window

- There is no perfect solution to this problem because there
  is simply no meaningful relationship between commit order and
  commit dates, with this solution we choose to assume commit dates
  will at least mostly be approximately chronological

- On the other hand, when a revision range is specified we chose
  to get the git blame information for the revision marking the end
  of the analysis window

Signed-off-by: Mitchell Joblin <mitchell.joblin.ext@siemens.com>
Fixes to return the integration test to a working state

Signed-off-by: Mitchell Joblin <mitchell.joblin.ext@siemens.com>
Bug fix: Check if file is deleted before calling git blame

- Check the list of files that are currently being tracked
  at the specific revision to prevent execution termination
  from calling git on deleted files

- The list of filenames touched by the list of commits can
  included files that are deleted by that commit, these
  deleted file are just ignored during the blame analysis

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