feat: CARv2 characteristic extensions

[rvagg]

Came up in the context of ipfs/specs#431, a combination of these characteristics might be useful to define a CARv2 trustless-http format that doesn't have an index but can do some additional signalling and provide metadata, while still wrapping a pristine, trustless CARv1.

[rvagg]

The messaging field is already demonstrated in ipld/go-car#322 & ipld/js-car#89.

[rvagg]

As noted in this, one of the weaknesses of the characteristics approach is that it doesn't really help us add new things which are breaky. I've suggested in here that implementations might want to start signalling when they see a bit that they don't know about and warning users in some way ("hey, maybe upgrade me, I don't know what this bit is about"). The most problematic new bit introduced here is zero-terminated-payload which allows the data-size header field to be 0 and the payload be terminated by an 0x0 section. Existing implementations will see data-size of 0 and decide there's nothing in there. You'd have to upgrade your CAR utility/library in order to successfully read one of these.

[willscott]

I'm not totally convinced by this use.
It will with high-likelihood create situations where implementations create the same car bytes but don't set a characteristic bit to indicate e.g duplicates vs no-duplicates.

This then leads to a question of what the 'canonical' car would be for a dag, and makes matching of expected responses one level more nuanced / harder.