Unicode API rework

[bindreams]

Fixes #845 as discussed.

Comparing the two approaches of getting argv:

1. The "old" way, through CLI::argv():
   ✔️ Works automatically and almost everywhere
   ❌ Small abstraction overhead on macOS
   ❌ Does not work in weird edge-cases such as missing /proc
2. This PR, through app.ensure_utf8:
   ✔️ True zero-overhead abstraction: you don't pay for what you don't use
   ✔️ Less moving parts than the "old" approach, probably can't be broken
   ❌ Requires extra code to be written by the user (which is sad because ideally everyone should use this by default)

[codecov]

Codecov Report

Patch coverage is 100.00% of modified lines.

Files Changed	Coverage
include/CLI/App.hpp	ø
include/CLI/impl/Argv_inl.hpp	ø
include/CLI/impl/App_inl.hpp	100.00%

📢 Thoughts on this report? Let us know!.

[bindreams]

@henryiii PTAL. Implemented this before your comment about axing CLI::argv. The way it works here is CLI::argv is available but completely optional. Do I still cut it out? I'll be honest, I'm sad to see it go 😢.

[henryiii]

I was thinking this:

int main(int argc, char** argv) {
     CLI::App app{"App description"};
     argv = app.ensure_utf8(argc, argv);
     CLI11_PARSE(app);
     return 0;
}

That is, calling ensure_utf8 stores the (new on windows) argv in the app on all platforms. Then it's legal to call CLI11_PARSE with just app, no additional magic needed. That's a little bit more complicated than before, but slightly better than having to list argc/argv again. You don't even need the argv = part if you aren't going to use it later. If it hasn't been stored, I was originally thinking we could make CLI11_PARSE(app) an error, though if you still wanted to have the CLI::argv() work, then it could use that.

The downside is it's not as obvious how inject modification of argv in this form, of course.

These are the possible usages:

// 1
app.ensure_utf8(argc, argv);
CLI11_PARSE(app);  // Uses stored argv vector on all platforms

// 2
argv = app.ensure_utf8(argc, argv);
CLI11_PARSE(app, argc, argv);  // Uses produced argv vector

// 3
CLI11_PARSE(app, argc, argv); // Not unicode

// 4
CLI11_PARSE(app); // Not portable, but unicode

My favorite probably is 2, as it's explicit, but 1 is pretty simple looking for most users who don't manipulate argv first, and can be written as 2 if a user does need to. I'm fine to drop 4 as too magical and not portable, but if we keep CLI::argv(), we could keep that too. Some people might like the brevity and not care about portability. But 1 is pretty simple.

[henryiii]

This looks like an improvement, my main question is, would it make sense to support (1) above and maybe drop (4)? (In later PRs)

[henryiii]

@phlptp thoughts about API in follow-ups? I’ll approve this PR tomorrow.

[phlptp]

I don't have any strong opinions on the unicode stuff, so this seems reasonable to me.

[bindreams]

Thanks for the merge!

Would you mind putting in a word with the all-contributors bot about my contributions? Sorry for being indiscreet.

[henryiii]

@all-contributors, please add @andreasxp for code

[henryiii]

(Not totally sure the bot is still working, we might need to update manually, feel free to ping (a lot) if we forget!)

[henryiii]

Done in #977.