The commit conventions enforced by commitlint (conventional) were different than the conventions used by the semantic-release (angular). In practice, is was never a problem as they are pretty similar, but it's better to be consistent anyways. Update the commit conventions documentation according to the change and also extend it with the information about which kind of release is triggered by which commit type. Add explicit configuration for release rules for semantic-release to the configuration file - rules are the same as before, but now it is easier to see what they actually are.

Previously, we relied on husky package to set up the Git hooks to automatically lint code and check the commit message conventions. While it is a nice feature it causes extra delays on commit/push for more experienced contributors and we still get many PRs with incorrect commit messages from the first-time contributors. Given the above reasons remove the husky dependency, Git hooks and replace them with a script which can be used locally. Note that CI continues to validate the commit message conventions as before.

For some projects, a preprocessor like TypeScript may run to downlevel
certain features to a lower ECMAScript target. e.g. a project may
consume Angular for example, which ships ES2020.

If TypeScript, ESBuild, Babel etc. is used to do this, they may inject
generated code which does not map to any original source. If any of
these helpers (the generated code) is then part of a stack trace, Karma
will incorrectly report an error for an unresolved source map position.

Generated code is valid within source maps and can be denoted as
mappings with a 1-variable-length mapping. See the source map spec:
https://sourcemaps.info/spec.html.

The warning for generated code is especially bad when the majority of
file paths, and the actually relevant-portions in the stack are
resolved properly. e.g.

Errors initially look like this without the source mapping processing
of Karma:

(See PR description as commit lint does not allow for long stack
traces..)

A helper function shows up in the stacktrace but has no original mapping as it is
purely generated by TypeScript/ESbuild etc. The following warning is
printed and pollutes the test output while the remaining stack trace
paths (as said before), have been remapped properly:

```
SourceMap position not found for trace: http://localhost:9877/base/angular_material/
  src/material/select/testing/unit_tests_bundle_spec.js:26:26
```

The resolved stacktrace looks like this after the transformation:

(see PR description as commit lint does not allow for long stack traces
here..)

More details on the scenario here:
https://gist.github.com/devversion/549d25915c2dc98a8896ba4408a1e27c.

## [6.3.8](v6.3.7...v6.3.8) (2021-11-07)

### Bug Fixes

* **reporter:** warning if stack trace contains generated code invocation ([4f23b14](4f23b14))