[chloggen] Add repo-level option to generate multiple changelogs

[djaglowski]

Change logs are written for a particular audience. Some of our repos have more than one audience, each of which is concerned with a different set of changes.

As noted here, the collector-contrib repo should consider end users and component developers as separate audiences. (And some people such as maintainers may be members of both audiences.) End users are concerned with changes to the behavior of the collector, while component developers are concerned with changes to exported elements of the packages.

I propose that chloggen be enhanced in such as way that it is possible for each repository to opt into the following:

1. Articulate a list of change logs, each corresponding to an intended audience (e.g. user, api)
2. Ask contributors to specify one or more change logs for which an entry is intended.

The implementation would involve the introduction of a repo-level configuration file that might look like this:

# Optional. By default a log with description "Changelog"
change_logs:
  - name: user
    title: End User Changelog
  - name: api
    title: Go API Changelog

# Optional. May be set to one or more logs named in 'change_logs'.
# An empty list indicates that contributors must specify the 'change_log'.
default_change_log: [user, api]  

A repo that opts into these new features would update their TEMPLATE.yaml roughly as follows:

# Use this changelog template to create an entry for release notes.

# Optional: The change log or logs in which this entry should be included.
# e.g. 'change_log: [user]' or 'change_log: [user, api]'
# Include 'user' if the change is relevant to end users.
# Include 'api' if there is a change to a library API.
change_logs: []

# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
change_type:

# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver)
component:

# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
note:

# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
issues: []

# (Optional) One or more lines of additional information to render under the primary note.
# These lines will be padded with 2 spaces and then inserted directly into the document.
# Use pipe (|) for multiline entries.
subtext:

Open Question:

Should each change log be written to its own file or just broken out within the same file? Separate files could be supported by including a file field in the change_logs config. Otherwise, this is a matter of updating the embedded template.

[dmitryax]

Should each change log be written to its own file or just broken out within the same file? Separate files could be supported by including a file field in the change_logs config. Otherwise, this is a matter of updating the embedded template.

I think they should be separate files. It'll allow us to render the same entry in different files and with a clean structure.