Introduce identifiers for fsck messages

Rather than specifying only whether a message by the fsck machinery
constitutes an error or a warning, let's specify an identifier relating
to the concrete problem that was encountered. This is necessary for
upcoming support to be able to demote certain errors to warnings.

In the course, simplify the requirements on the calling code: instead of
having to handle full-blown varargs in every callback, we now send a
string buffer ready to be used to the callback.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Provide a function to parse an fsck message type

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Offer a function to switch fsck errors to warnings and vice versa

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Allow demoting errors to warnings via receive.fsckobjects

The value can now be a list of options of the form '-missing_email'.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a test for non-boolean receive.fsckobjects values

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
TODO: Disallow demoting grave fsck errors to warnings

Some kinds of errors are intrinsically unrecoverable (e.g. errors while
uncompressing objects). It does not make sense to allow demoting them to
mere warnings.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make fsck_ident() warn-friendly

When fsck_ident() identifies a problem with the ident, it should still
advance the pointer to the next line so that fsck can continue in the
case of a mere warning.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
TODO
Document the new options for receive.fsckobjects

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>