feat: add git repo auto initialization

[IlCallo]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• It's submitted to the dev branch and not the master branch
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• It's been tested with all Quasar themes
• It's been tested on a Cordova (iOS, Android) app
• It's been tested on a Electron app
• Any necessary documentation has been added or updated in the docs (for faster update click on "Suggest an edit on GitHub" at bottom of page) or explained in the PR's description.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
We discussed this many times, I took inspiration from how Vue CLI does it, but simplified it greately since it was too complicated for our actual needs.

While I was at it, I also:

• refactored a bit to use async/await where possible
• provided more precise errors (failing linting would say the deps install failed)
• made failed linting not fatal

[rstoenescu]

This is extremely useful, but let's try to do this from within "@quasar/cli" so that all starter kits to benefit.

[IlCallo]

Makes sense, forgot there were AE ones too
I guess I should make it default behaviour and add a --no-git flag for those who want to opt-out, right?

[IlCallo]

@rstoenescu I tried to add it into quasar/cli, but that's not so simple.

The last hook we have into starter kit creation process is the end of template generation, as currently the starter kit complete callback isn't async, it just spawns a new process (it is async in this PR as I refactored it to be as such).

Right now, scaffolding completes, git repo is initialized, then linting takes place: those code updates won't be caught.

The solution I propose is to first update all starter kits to return an async complete, then await it on the cli and execute git initialization afterwards

Another problem: minimist won't accept parameters with dashes in the midde (eg, --no-git).
We probably should switch to something like commander which seems to have a better DX and is currently maintained. As a workaround, for now, I'll use --nogit without the dash

[rstoenescu]

Sounds good.
One thing though. The linting should happen before git repo initializes. As in "hey, we're done, this is your project. Now adding git to it".

[IlCallo]

Yeah, that's the main problem I'm trying to solve.
I'll avoid logging anything related to git initialization: it's a transparent process which should log only if something goes wrong, and it would "push up" the final message from the starter kit (which is the important one)