[kaihere14]

Follow-up to #2369.

Problem

Warnings about bad lines in ccextractor.cnf were logged inside ccxr_parse_parameters before the command line was parsed, while the logger still targeted stdout. So:

• with -stdout, the warnings were written into the caption output ahead of the captions, which corrupts the SRT for anything reading the pipe;
• with -quiet, they were still printed.

Reproduced with a ccextractor.cnf containing NO_SYNC=yes and BOGUS=1, and a small SCC file:

Run	stdout before	stdout after
-stdout	2 warning lines, then the SRT	SRT only (warnings on stderr)
-quiet -stdout	2 warning lines, then the SRT	SRT only, nothing on stderr

Fix

• Hold the cnf messages back, point the logger at the parsed messages_target, then print them. -stdout sends them to stderr and -quiet silences them, like every other message.
• docs/ccextractor.cnf.sample: fix the FIX_PADDINDG and INVASTIGATE_PACKET typos, add the missing = to FORCED_RU, START_AT, END_AT and MP4_VIDEO_TRACK, and list the tags that are actually read. The other tags in the sample were never supported by the C parser either, and they are now reported as unknown.

Testing

Built with mac/build.command and ran the cases above. cargo test -p lib_ccxr config_file passes (6 tests). There is no unit test for the ordering, since it lives in the extern "C" entry point.

[kaihere14]

@cfsmp3 ready for a review whenever you get time!