WIP: Introduce fsck options

Just like the diff machinery, we are about to introduce more settings,
therefore it makes sense to carry them around as a (pointer to a) struct
containing all of them.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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.

While at it, simplify the requirements on the calling code: instead of
having to handle full-blown varargs, we now send a string buffer ready to
be used by 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>
WIP: Add a test for non-boolean receive.fsckobjects values

TODO!!! This only *happens* to work because the fsck machinery is
ill-prepared to handle warnings. It is based on the concept that we can
simply error out when there is so much as even a warning, but what we want
to do is to try to figure things out and continue even after detecting
that, say, an email is missing or invalid.

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

This demonstrates what needs to work, and does not yet.

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