Switch from CommandLineParser and McMaster.Extensions.CommandLineUtils to System.CommandLine

As of today, we are using:

- CommandLineParser to parse arguments for BenchmarkSwitcher
- McMaster.Extensions.CommandLineUtils to parse the arguments for our first global tool (#1006)

Having two dependencies to parse command line arguments is not good.

I think that we should switch to `System.CommandLine` if possible ([project](https://github.com/dotnet/command-line-api))

System.CommandLine is the future of parsing command line arguments in .NET. It's not a MS-only project, it has been built together by the community and MS based on experiences from many existing command line parsing projects.

I have seen a 1h internal demo at MS and to tell the long story short it has everything that `CommandLineParser` and `McMaster.Extensions.CommandLineUtils` have and a lot of more cool features. You can read more about the motivations for it [here](https://github.com/dotnet/command-line-api/wiki/Technical-motivations)

What this task requires:

1. Make sure that `System.CommandLine` supports everything that `CommandLineParser` gives us as of today:
- parsing simple arguments (1 value)
- parsing more complex arguments (`IEnumerable`)
- parsing arguments with aliases (example: `-i --inprocess`)
- help with samples
2. Making sure that `System.CommandLine` supports everything that `McMaster.Extensions.CommandLineUtils` gives us as of today for the global tool

The global tool was merged to https://github.com/dotnet/BenchmarkDotNet/tree/tools branch. So a person working on this task would have to create branch out of `tools` branch.

If `System.CommandLine` meets all our needs, then I can talk with @KathleenDollard about publishing a signed package to Nuget.org and we can switch (https://github.com/dotnet/command-line-api/issues/356)

@wojtpl2 perhaps you would be interested in this issue?