Add validation of scanf format and arguments

[Luhrel]

@WalterBright asked for it in the forums, so here it is.

Highly inspired by #10812.

[dlang-bot]

Thanks for your pull request and interest in making D better, @Luhrel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#10852"

[RazvanN7]

Most of the logic here seems like a duplicate of chkprintf.d. Is there any difference between the mirrored functions? Even if there is, it should be minimal. I suggest that chkprintf file is renamed to chkformat and try to reuse the code as much as possible. For example: the parseFormatSpecifier function should be identical for both situations, there is no need in duplicating it; even if there are some differences, those should be special cased with if-else branches. Another example is the enum Format declaration: 2 declarations of the same thing.

[thewilsonator]

Are sscanf and fscanf supported? (also for that matter sprtinf and fprintf?)

[Luhrel]

Most of the logic here seems like a duplicate of chkprintf.d. Is there any difference between the mirrored functions? Even if there is, it should be minimal. I suggest that chkprintf file is renamed to chkformat and try to reuse the code as much as possible. For example: the parseFormatSpecifier function should be identical for both situations, there is no need in duplicating it; even if there are some differences, those should be special cased with if-else branches. Another example is the enum Format declaration: 2 declarations of the same thing.

Done.

Are sscanf and fscanf supported? (also for that matter sprtinf and fprintf?)

Now, yes.

[thewilsonator]

Also the changelog should mention that the file and string variants of scanf are also validated. This changelog entry should be merged with the printf one (if that hasn't already been released). It should also mention that fprintf and sprintf are also validated.

Review addressed

[thewilsonator]

This PR seems to have some issues with real. See the autotester for details e.g. https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=3964672&isPull=true

[WalterBright]

The errors in the test suite are about druntime's use of sprintf. This is why sprintf support should not have been lumped into this PR, as this PR is putatively about scanf.

I recommend removing fprintf and sprintf from this PR and putting them in a separate PR.

[Luhrel]

Done. @WalterBright Maybe you can merge this now.