"-strict_mime_boundary 1" searches for incorrect boundary

[barsnick]

Summary of the bug:
The mpjpegdec option "-strict_mime_boundary 1" applies an incorrect boundary to its search in the stream.

How to reproduce:
Use the option "-strict_mime_boundary 1" with an mpjpeg input stream which adheres to the boundary definitions, and doesn't provide a Content-Length MIME header. (Examples given in #5023.)

Prerequisite for reproduction: Fix #7920.

[barsnick]

Root cause:
The boundary parameter string found in the Content-Type header is not prepended with "--". The exact match string mpjpeg->boundary is taken is taken directly from the parsing of the header; the precise binary match string mpjpeg->searchstr is also created from the parsing, with additional "\r\n" added before and after.

RFC1341 says:

The Content-Type field for multipart entities requires one parameter, "boundary", which is used to specify the encapsulation boundary. The encapsulation boundary is defined as a line consisting entirely of two hyphen characters ("-", decimal code 45) followed by the boundary parameter value from the Content-Type header field.
[...]
Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. The boundary must be followed immediately either by another CRLF and the header fields for the next part, [...]

In other words, the boundary found in the header's parameter shall be encapsulated as:
"\r\n" + "--" + boundary from header + "\r\n"
What mpjpegdec does is to only encapsulate it with "\r\n":
​https://github.com/FFmpeg/FFmpeg/blob/b401a4ab8aa85c536bd9eee0da8f51551b66c70e/libavformat/mpjpegdec.c#L309