Issues making packages for EPEL7

Hi all! Awesome work creating this tool, we (Arrikto) are trying to use it to package our Python dependencies.
We are currently having an issue with the generated SPEC files for EPEL 7.

For example, we are trying to build a package for package`mockldap`.
These are the generated dependencies:
```rpm
BuildRequires: python2-devel
BuildRequires: python2-funcparserlib = 0.3.6
BuildRequires: python2-ldap
BuildRequires: python2-setuptools
BuildRequires: python2-setuptools >= 0.6~rc11
BuildRequires: python2-mock
BuildRequires: python2-sphinx
```

However, some of those will not work, because there are only `python-X` packages, not `python2-X` packages.
I would expect dependencies in EPEL7 to use the unversioned format because:
* If it's an old dependency, it will work.
* If a newer, versioned package has been released, it should declare that it provides the unversioned package.

I see that this format was removed in #128. However, this leads to SPEC files that cannot find the packages they need.

In addition, the SPEC files generated by `pyp2rpm` for EPEL 7, with the `epel7` template, provide only `python2-x` and not `python-x`.

My understanding from reading these sources:
* https://python-rpm-porting.readthedocs.io/en/latest/modules.html#python-provide
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_the_python_provide_macro

is that the correct way to do this is by using the `python_provide` macro.
I see that this macro is available in my RHEL 7 host, so we should be able to use it in the EPEL template.
I also see that other templates are already using it (e.g., the Fedora one).

In conclusion, our proposal is to:
1. Use unversioned python packages for dependencies in EPEL 7.
2. Provide the unversioned package in SPECs generated with `pyp2rpm`, with the `python_provide` directive.

What do you think?