as ApprovalDevScore has the same behavior as EmojiDevScore, it is not a
good idea to check if this datetime is zero or not to select the scoring
system.

As ApprovalDevScore has been changed to be return a Zero Time if non
strict (aka if this is a Developer MR) to be consistent with the
EmojiDevScore, there is a scenario where the check will not be able to
determine the real "waiting time".
This may appear if:
- this is a Developer MR
- Some other Developer approves the MR really soon (lastSignChange ==
  Zero now)

also explicitely enabling revive linter that seems to be a replacement
for (obsolete) golint

Track the explicit Reviewer set in MRs, and wait for the Reviewer
feedback (and set the WaitingForReviewerFeedback status).
If the Reviewer add some feedback in the MR, resume the review process.

Fixes #8

resource_group keyword should make the homer schedule exclusive, and
avoid having multiple script launch at the same time.

Emoji strategy was selected only during the transition phase.
Approval strategy is supposed to be the one used on new MRs.

if one of the strategy has no vote and the other one has at least one
vote, choose the latter.

homer now checks if some new version of the MR has been pushed to
estimate if the Stale status should be set.

Fixes #17.

The goal is to avoid upvotes/approval to extend the "no review"
deadline. This happened when a developer was approving/upvoting a MR:
- between 0h to 24h before the "no review" deadline (the MR switches from
  "Reviewable" to "Acceptable" and wait 24h after the vote).
- after the "no review" deadline (the MR switches from "Accepted" to
  "Acceptable" and wait for 24h to go back to its previous state).

Ignoring the presence of votes if there are only upvotes/approvals for
the "no review" transition should solve both issues without any
consequence on the other part of the process:
- if the upvote occurs between 0-48h after the creation of the MR, then
  the "no review" transition will fail during the 0-72h period (deadline
  not reached). During this period, the MR will considered Acceptable,
  then Accepted 24h after the first upvote. After 72h, the "no review"
  transition will succeed no matter what.
- if the upvote occurs between 48-72h, the "no review" transition will
  fail, MR will be switched to Acceptable. But after 72h, the "no
  review" transition will succeed no matter what, switching MR to
  Accepted.
- if the upvote occurs after the "no review" deadline, the "no review"
  transition will succeed no matter what, so the MR will be kept as
  Accepted.

Note: all these statements suppose there is no (resolvable/resolved)
discussion thread opened and/or closed on the MR at all. If this is the
case, the "no review" transition will fail in any situation, and the
process will fallback to the previous workflow behavior.

Fixes #16.

The new "Inactivity" deadline for Developer+ MRs now takes into account
both the first version of the MR and the last version of it.

With the default threshold values, the goal is to put developer unreviewed MRs
in Accepted state after the later of 24h after the last non simple change
(ie fast-forward rebase) and 72h after the MR creation time (or
out-of-draft time).

Fixes #15

MR that are "stuck" in InReview status for a certain amount of time
without any user activity (60 days by default) will be considered as
"Staled", and put in the according state.

DevScore is supposed to return the last time the score changed its sign.
With approval method, score sign cannot change more than once:
- either the score is zero (no vote)
- or the score is strictly positive since the first approval
So the time returned by the function must be the time of the first
approval (and not the last).

MR Developer score can now be computed through two different methods:
- the old one based on the thumbsup/thumbsdown emojis
- a new one based on the Developers approvals

The bot tries to determine which method should be used to compute the
vote: if only one method provides a valid score (with a correct update
time), it is selected. In any other case, the `preferred-score-method`
parameter is used.

Fixes #10

System notes (notes with flag "system=true") seem to be the only way to
get the "all resolve thread" event.

Fixes #9

Add the ability to select specific MRs to be processed.
This is mainly for debug purpose.

By comparing MR version diffs, it should detect simple rebases.
Ignore these versions to get a more accurate value of the MR version
creation date.

This is not relevant for now