fix: Ignore packages that are not plugins

[mmartinortiz]

When a package starting with a plugin name is found, but it is not a plugin, it becomes safely ignored.

Description

When a packages has a name that matches a plugin, but it is not a plugin, it is safely ignored and reported to the user.

Background: The company where I work, and where I use commitizen for releasing package versions, is called CZ. And because we are not very imaginative, we use to call the packages that we develop for internal use something like cz_.

This collides with the way that commitizen discover plugins, and the discovery process raises an exception when a package starts with the name cz_ is found but is not implemented as a plugin.

This MR proposes a way to ignore those packages that collide in name but are not plugins. This proposal tries to be as agnostic as possible, not very Pythonic, but I am open to suggestions.

Checklist

• Add test cases to all the changes you introduce
• Run ./script/format and ./script/test locally to ensure this change passes linter check and test
• Test the changes on the local machine manually
• Update the documentation for the changes

Expected behavior

When the CLI searches for plugins, those packages that have a name cz_ but lack the discover_this attribute, will be ignored and the user will get a warning

Steps to Test This Pull Request

1. Create a package with a name starting with cz_. It can be located under a src folder
2. Install commitizen
3. Run commitizen changelog --help. Without this patch, an exception will be risen.

Additional context