flag unlabeled PRs with wildcard label

[NathanPJF]

Fixes https://github.com/lerna/lerna-changelog/issues/74

👋 Hi there, I'm working on a project with a distributed team and we were looking for a way to generate changelogs/releases easier. The challenge we ran up against is essentially the problem identified in https://github.com/lerna/lerna-changelog/issues/74.

To address this, I made a change to identify any commits that didn't have a label from the config with a "wildcard label" (name taken from the linked issue). I have details on how it works in the README.md. I wanted to share my approach to see if it is something you feel is useful before I go forward with writing test and whatnot 😃

Result

Example from my testing:

  "changelog": {
    "labels": {
      "breaking change": "💥 Breaking Change",
      "enhancement": "🚀 Enhancement",
      "bug fix": "🐛 Bug fixes",
      "unlabeled": "🤔 Unlabeled"
    },
    "wildcardLabel": "unlabeled",
    "cacheDir": ".changelog"
  }

## Unreleased (2019-05-04)

#### 🚀 Enhancement
* [#838](https://github.com/foo/bar/pull/838) Update search results layout ([@NathanPJF](https://github.com/nathanpjf))

#### 🤔 Unlabeled
* [#903](https://github.com/foo/bar/pull/903) Unhide mute button ([@somePerson](https://github.com/somePerson))
* [#923](https://github.com/foo/bar/pull/923) Convert hardcoded values ([@somePerson](https://github.com/somePerson))

Approach

I have details on my thought process in my fork, but essentially I felt the following was a good workflow:

1. wildcardLabel is optional and by default it has no value.
2. When there is a value, a default changelog heading is provided. Figured a default heading was fine as the tool already provides a number of defaults.
3. If you want a custom heading, you need to write the same label in the configuration labels along with a heading.

^ At first writing it in labels felt like duplication of effort. However, I realized the value for wildcardLabel could match a real label being used on GitHub to act as a safeguard for workflows where people are identifying PRs that need labeling. e.g. You have a typical workflow to label things on GitHub with unlabeled or for triage until you know whether the change is going to be a breaking one. Incase that PR never gets "properly labeled" before merging, you'd want a warning in place before you make that next release.

[rwjblue]

This seems neat to me, would definitely be useful in some projects I work in.

[Exelord]

This is awesome! Exactly what I was missing.

[shrkw]

I love this PR ❤️

[mansona]

Hey 👋 has there been any movement on this PR? I'm particularly interested in it because I'm working on something that makes use of these changes and I would love an official release 🙏