[v2] introduction of content_id

[Eric Wong <e@80x24.org>]

In addition to the git object_id (blob SHA-1) and Message-Id
header; it seems necessary to introduce an in-between identifier
for deduplicating which isn't as loose as Message-Id or as
strict as object_id: content_id

I think a hash of the following raw headers + raw body will
suffice:

	Subject, From, Date, Message-Id, References, To, Cc,
	In-Reply-To, MIME-Version, Content-Type,
	Content-Disposition, Content-Transfer-Encoding

Those should be relevant to what MUAs display to users.

Fwiw, ssoma only used Subject + raw body if Message-Id matched;
and public-inbox v1 only uses Message-Id.

List-Id, X-Mailing-List should be left out so different
readers/lists can share spam removals in cross posts.
Received: headers will definitely not be taken into account
as every recipient sees a different chain(*)

The code also won't be tied to any particular hash so it should
be possible to switch to another one as weaknesses are discovered;
and it could be possible to support multiple hashes in an
"inbox"

I also took a look at Razor and DCC anti-spam stuff, but both
seem to take fuzzy matches to avoid hash busting; but IMHO the
bar needs to be higher for handling removals from the archive.


(*) I noticed the first Received: header (last hop) is missing
    from the cregit sources; but the first remaining Received:
    header also includes the identity of the recipient in more
    recent mails...