More robust submodule summary insertion
More robust submodule summary insertion

Previously we tried to guess whether we should prepend or append the
submodule summary, depending on what (apparent) action appeared to be
taking place (eg. rebasing, amending, normal committing etc).

This turned out to work most of the time, but there are situations in
which neither prepending not appending is the right thing to do; for
example, when a change is being amended and it has user-supplied content
at the top, and auto-generated content at the bottom (eg. Change-Ids or
Signed-off-by: annotations).

Likewise, when there are release notes, we don't want the submodule
changes to be included in them; rather they should appear above them.

So, this commit rips out the old logic and replaces it with code which
scans through the proposed commit message looking for something which
flags the "end" of the main body; that includes things like:

  - comments (inserted by Git when preparing the message for editing)
  - commit "metadata" such as Change-Id, Signed-off-by, and friends
  - a release note header

At that point, it inserts the submodule summary and then lets the rest
of the message go through unaltered. In the almost inconceivable case
that it gets to the end of the message without finding any of those
flags, it inserts the summary at the end.

As far as I can tell, there's only one case in which this will do the
wrong thing, and that is if your commit message has something
pathological in it like a release note header half-way through the
message body (but if that's the case then release note extraction code
in Starways will also do the wrong thing with your message anyway, and
you'll still have a chance to notice the problem because you'll be
dumped into an editor with the submodule changes inserted in the wrong
place; hopefully you'll see the problem and fix it).

Change-Id: I908d9d2af9a37e601da84b3abdff88dfac5e6b20
Reviewed-on: https://gerrit.causes.com/572
Tested-by: Greg Hurrell <79e2475f81a6317276bf7cbb3958b20d289b78df@causes.com>
Reviewed-by: Jimmy Kittiyachavalit <04d98d2819faf945261d3b827ba4c12a65c36405@causes.com>

blech75/overcommit,oxocode/overcommit,oxocode/overcommit,TheSooth/overcommit,gnagel/overcommit,blech75/overcommit,TheSooth/overcommit,gnagel/overcommit