doc (git): commit message standards

# Feature Request

## Motivation Behind Feature

Improve the CHANGELOG readability by including to the git commit messages `type` and `scope`.

## Feature Description

Change and or improve on our existing git commit message standards.

## Background

Currently I been using a modified version of:

* https://karma-runner.github.io/1.0/dev/git-commit-msg.html
* https://www.conventionalcommits.org/en/v1.0.0/

Some of these fit well, reads well, and potentially reduces the message size.

Here is an example list of what I try to follow. It also contains my modification to what I seen in the website above. Also, as a side note, I sometimes even forget or use or use the wrong tag:

* `feat` - new feature
* `fix` - bug fix
* `docs` - documentation
* This one may not be necessary in `cordova-docs` as almost 90% of changes should be doc related, but if we include `blog` for the blog posts, then we could continue to use `docs` for separation.
* `style` - formatting
* `refactor` - refactoring of code, variable renaming, etc
* `test` - all test related changes (adding, refactoring, deleting)
* `chore` - internal tasks (updating dependencies, etc)
* `breaking` - to reference a breaking change
* `ci` - CI related changes (update, add, delete CI recipes, services, etc.)

Example usage:

```
feat: add adaptive icon
fix: returning incorrect icon size
docs: adaptive icon usage
style: applied eslint change request
breaking: removed legacy icon support
ci: added xcode 11 to travis
```

We can also include `scoping` to increase understanding of where a change might have been and maybe even reduce the size of the message.

Example format: ` (): `

Example usage:
```
docs (android): adaptive icon usage
style (eslint): applied change request
ci (travis): added xcode 11
```
Remember, the first summary or excerpt line should be limited to 50 chars. The following lines can be how ever long.

Current Guidelines are located here: https://cordova.apache.org/contribute/contribute_guidelines.html

## Final Notes

This ticket is to only:
* document some ideas
* explain a format I been using
* to include others for feedback

I am not trying to resolve, change, or enforced some guideline immediately so please do not try push this through ASAP.

At of the time of this posting, I am heavily focused on preparing major releases and hoping to get them out. If someone didn't follow the current or proposed guideline, I do not see any harm has it has not been very strict in the recent years. It current goal is to not block contribution or the major release process. The merger also has a chance to change the commit message when `squash & merge`.

I don't want to take too much time or effort away form the major release right now.