release-21.2: cli,log: allow use of debug merge-logs on older logs

[dhartunian]

@cameronnunez I think this PR was supposed to make it into 21.2 but it never did since the date looks like it was merged during stability and got forgotten in the shuffle. I'm trying to backport #79356 via #83147 and ran into some test failures and merge conflicts that made me realize there was a piece missing.

Seems straightforward that we should backport this since it was originally intended to be in 21.2 and helps with log management.

---

Backport 1/1 commits from #68282.

/cc @cockroachdb/release

---

Fixes #68278.

Log parsers require the flag --format when parsing older logs (because
they do not contain format specification). With this patch, this is no longer
a requirement as the log format is now inferred based on the structure of
the log if no log format specification exists.

Release justification: bug fix

Release note (bug fix): The debug merge-logs command no longer returns an error
when the log decoder attempts to parse older logs.

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues or test-only changes.
• Patches should not break backwards-compatibility.
• Patches should change as little code as possible.
• Patches should not change on-disk formats or node communication protocols.
• Patches should not add new functionality.
• Patches must not add, edit, or otherwise modify cluster versions; or add version gates.

If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters.
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.

Add a brief release justification to the body of your PR to justify this backport.

Some other things to consider:

• What did we do to ensure that a user that doesn’t know & care about this backport, has no idea that it happened?
• Will this work in a cluster of mixed patch versions? Did we test that?
• If a user upgrades a patch version, uses this feature, and then downgrades, what happens?

[cockroach-teamcity]

This change is 

[dhartunian]

@cameronnunez friendly ping :)

[abarganier]

from my end!

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @cameronnunez)

[dhartunian]

Merging since this seems uncontroversial and the diff is identical to the original.