Add binlog filepath uniquification option

[JanKrivanek]

Fixes #8817

Context

There are cases where explicit unique binlog paths cannot be specified and the implicit overwriting behavior is complicating the invectigations (e.g. the implicit separate restore step invoked by sdk - as per #9614).

For those cases let's introduce a simplistic uniquification opt-in mechanism: When specifying a '{}' substring withing the binlog path parameter - this is going to be expanded into a timestamp plus random stamp.

Behavior:

• Only '{}' is recognized and expanded. If the brackets have any content - it's intentionally left untouched (this can be added in future iteration if there is any need)
• If '{}' is present, then the '.binlog' extension is ensured (whether specified in original name or not)
• Each '{}' in the binlog path argument is replaced with timestamp and random string stamp
• Custom expander can be injected - this is mainly for unit tests, but can be used if anyone wants different uniquification
• Intentionally no build-time information (entrypoint project, target, etc) is added - KISS principle. All needed information can be located within the binlog. We can iterate on this if requested and needed.

Samples:

• -bl:{} --> 20240423-102016--16636--anxG+w.binlog
• -bl:LogFile=MyBinlog-{}.binlog --> MyBinlog-20240423-102016--16636--anxG+w.binlog
• -bl:{something}.binlog --> {something}.binlog

Changes Made

The parameters parsing is extended, so that it can recognize and expand '{}'

Testing

Existing tests. + added tailored tests for pre-existing and new naming interpretation

Notes

This can technically be breaking - but the likelyhood is quite low (I tried to search GH and ADO for usage of binlog, where explicit path would be specified and contained '{}' - and found none). S I'd prefer clean experience rather then adding additional commandline arguments. It is still behind the change wave - if anything goes wrong.

FYI @KirillOsenkov

[f-alizada]

Sorry for delaying with the PR and proper fix for the opt-in mechanism, the changes looks good.
If the completely opt-in mechanism will be required please let me know, I have some draft changes that could be used as well :)

[JanKrivanek]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[KirillOsenkov]

I like the design!

I feel pretty strongly that we should remove the interface and just use Func<string> to obtain the random string. If it's null, fall back to the default (current) implementation.

Nothing in this PR should be adding any new public API.

Also would be nice if the process ID of the node was featured in the random string.

Also let's add a dash between date and time.

[JanKrivanek]

I like the design!

I feel pretty strongly that we should remove the interface and just use Func<string> to obtain the random string. If it's null, fall back to the default (current) implementation.

Nothing in this PR should be adding any new public API.

Also would be nice if the process ID of the node was featured in the random string.

Also let's add a dash between date and time.

Update format based on suggestions - the sample result is in the updated PR description