Add adapters-repo hooks

還沒有人認領這個 Issue。

As an adapter author, I want to be able to have my adapter be configurable (data) and also be able to tap into hook functions (events). I want repo maintainers to be able to define paths to hooks in a similar manor to what we let adapter maintainers do in the commitizen cli-adapter relationship. In the cli-adapter relationship there is really just one hook (prompter) that runs the prompter method of the adapter. Ideally we'd have more hooks available to allow the cli-adapter-repo chain to be solid and configurable.

I would imagine that both the cli-adapter and the adapter-repo relationship need more hooks to be effective. I'm not really sure exactly what points people would want to tap into but this is something I'd love to hear more about from adapter maintainers.

Specifically, if I maintain cz-conventional-widgets, I might decide that I want someone who maintains the AwesomeWidgetBuilder repo to be able to define the following in their package.json:

```
{
config: {
commitizen: {

// HOOKS: All hooks are exports of one file, hooks is an array, with index 0 being the path
hooks: ['myfile.js', 'init', 'bootstrap'];

// -- OR --

// HOOKS: Each hook is in its own file, hooks is an object
hooks: {

// SIMPLE HOOK ITEMS: the exported bootstrap method gets run from myRepoCzSettings.js
"bootstrap": "./myRepoCzBootstrap.js",
"end": "./myRepoCzEnd.js",

// -- OR --

// ADVANCED HOOK ITEMS: an object is used and we call mySweetInitFunction in the init hook
"init": {
path: "./myCzRepoInit.js",
function: "mySweetInitFunction"
}

}
}
}
}
```

This way my adapter and any other adapters that follow my interface can make calls into the repo paths and expect to get data back from the repo.

Note that because the config paths are not scoped to a specific adapter but rather to a series of hooks, an adapter that uses a different commit style could still implement the interface and serve the repo owner. Specifically, if I use the widgetReader interface hooks then I can use either cz-conventional-changelog or cz-smart-commit without having an issue so long as the adapters follow the interface an calls certain hooks at expected times in the execution flow.

先檢視現有的 cli-adapter 關係及其 prompter hook，接著將其與提議的 adapter-repo 關係進行比較。在尋找相關 CLI 與 adapter 程式碼之前，釐清維護者需要哪些生命週期 hook 以及何種設定結構。完成的標準是：達成共識的 hook 契約與 package.json 表示，並在整個執行流程中獲得一致支援。

由索引模型根據 Issue 內容生成。