Add `render` subcommand

[gdemonet]

Building on the list subcommand introduced in #4, we want to add the ability to generate a changelog / release notes from a list of fragments.

To select which fragments to include in the generated document, the same options as the list subcommand will be used. To control the output contents and format, the following options will be added:

• --release-notes will filter fragments to only include ones tagged with :release-notes:
• --kind $KIND will filter fragments tagged with :kind: $KIND, where $KIND can be one of Feature, Bugfix, or Improvement (more kinds may be added in the future); this option can be used more than once - not specifying it implies all kinds are included
• --epic $EPIC works similarly to the kind filter described above, but not specifying it allows to also include fragments without any :epic: specified; a --no-epic flag will be provided to only select such fragments
• --output $FMT will allow to control the format of the generated document, akin to many existing command-line tools (e.g. kubectl); the only supported format in this initial implementation will be reStructuredText

In this issue, we will not consider automatic retrieval of pull request information.

[NicolasT]

Instead of enforcing a set of possible values for kind, should there be some configuration (file)?

[NicolasT]

I'd rename this to render, and keep generate for another purpose (about to file an issue for it...)

[gdemonet]

Instead of enforcing a set of possible values for kind, should there be some configuration (file)?

Not sure... There would be more configuration than just what values are allowed for a kind, because we need to know how to render a section for this kind (each kind would have a template? what about the overall document template?). I think handling it this way requires more thought and effort, so let's keep it simple for now and maybe open an improvement task later, if we see the use-case.

I'd rename this to render, and keep generate for another purpose (about to file an issue for it...)

Good idea :+1:!

[NicolasT]

I think handling it this way requires more thought and effort, so let's keep it simple for now and maybe open an improvement task later, if we see the use-case.

:+1: Potential future improvement/extension point.

[NicolasT]

Wondering why list should not have the release-notes, kind, epic and no-epic flags...