Read package rename options via configuration file

When `create-release-branch` adds commits to a package's changelog, it regenerates the whole file. If the package was renamed at some point, however, the tag references at the end of the changelog will reflect the rename (that is, at some point, the tag name may change). The `core` repo (which has some of these types of packages, e.g. `json-rpc-engine`) communicates this rename to this tool (`auto-changelog`) by passing a couple of command-line options, `--tag-prefix-before-package-rename` and `--version-before-package-rename`. However, those options are local to `core` and this tool doesn't know about them when run elsewhere. So when this tool updates changelogs for those kinds of packages via `create-release-branch`, it resets the tag references, making them invalid from `core`'s perspective.

Instead of receiving this information through command-line options, this tool should receive it through a configuration file. This way, whether it is run via `core` or `create-release-branch`, it always generates the right changelog.

We could read the configuration file via `cosmiconfig` or some other mechanism.

Start by tracing how create-release-branch currently receives and applies --tag-prefix-before-package-rename and --version-before-package-rename, then inspect the auto-changelog entry point and configuration handling. Compare a cosmiconfig-based approach with the existing command-line flow. Done means renamed packages produce valid changelog tag references whether invoked by core or create-release-branch.

Written by the indexing model from the issue text.