Next odd commit affecting `git subtree split` experiments with contrib/elftoolchain

[Ed Maste]

I'm currently excluding the following additional revisions from
mergeinfo parsing (on gig_conv 9ae420c081):

242545
249429
250837
255263
255477
256424
265006
265006
265044
265547
265720
267888
283595

It may not be necessary to exclude all of these - they're just the
list I've arrived at, after iterative trial and error.

When I run `git subtree split --prefix=contrib/elftoolchain` this
includes some legitimate, unnecessary, but innocuous commits - e.g.
r298092 is included, which tracks a long-running project branch that
brought in elftoolchain updates in MFH commits, but didn't otherwise
touch elftoolchain on the branch. These clutter the history slightly
but cause no real issue.

I've found one new class of strange commit - r265044, which I've
excluded from mergeinfo parsing (in the above list). However, svnweb
highlights an issue:

https://svnweb.freebsd.org/base?limit_changes=0&view=revision&revision=265044
projects/bmake/contrib/elftoolchain/
(Copied from head/contrib/elftoolchain, r265036)

It looks like contrib/elftoolchain was added to svn head during the
time that the /projects/bmake/ was in use, and brought to that
projects branch via a MFH. It looks like this triggers svn2git's
existing svn cp-based merge detection. I think svn2git is doing the
right thing here, it just legitimately triggers the existing issue/bug
in subtree split.