Allow dav1d_get_picture to return information about which packet was bad

I'm currently dealing with a buggy H.264 encoder. Thankfully, I'm able to obtain some information about the corrupt packets (the H.264 decoder I'm using returns some information about which packet to blame for the decode failure).

I would like something similar for dav1d. I think this might be too big of a change for dav1d_get_picture, but I think this would be feasible with a new function (e.g., dav1d_get_picture2 or whatever). Ideally dav1d would return the Dav1dDataProps that is associated with the problematic packet if decoding fails. I'm imagining something like this:

/**
 * Return a decoded picture.
 *
 * @param        c Input decoder instance.
 * @param      out Output frame. The caller assumes ownership of the returned
 *                 reference.
 * @param bad_data Output data if the return value indicates an error. This will
 *                 only be set when an error occurs, but may not be set for all
 *                 errors (e.g., if dav1d can't determine which input data to
 *                 blame for the decode failure the bad_data won't be set). When
 *                 this is set, it might be only partially filled. For example,
 *                 the data's data pointer might be NULL (check sz) if dav1d
 *                 can't provide the input data's data. Even if sz is zero, the
 *                 m field might be populated with a useful information. If an
 *                 error is returned, pass this object to dav1d_data_unref (even
 *                 if sz is zero, as m.user_data might be set and need
 *                 releasing) when you are done with it to avoid leaking memory.
 *
 * @return same as dav1d_get_picture.
 */
DAV1D_API int dav1d_get_picture2(Dav1dContext *c,
                                 Dav1dPicture *out,
                                 Dav1dData *bad_data);

The exact name and API is open to bikeshedding, of course. An API like this would assist players in knowing which stream caused the error (e.g. during ABR switches when there are effectively 2 active video streams) and where in the stream the problem is (based on the PTS of the packet).