There seems to be no reason to actually have them. To quote myself:
> The Enterprise Customer used to be one-to-one to a reporting config, but later I switched it to be one-to-many instead because we should be able to have multiple data/report types per customer. However I thought there was a good reason to have a 1-to-1 relationship in the first place so I added the constraint on enterprise_customer to respect whatever reason that was. In hindsight there doesn't seem to be a good reason since we can still make multiple reporting configs per customer anyway...
*Merge deadline:* Whenever.
1. Run migrations with this in place.
2. Ensure you can add reporting configurations for the same customer as your heart desires.
[ ] Check that the versions of the requirements in the `platform-master.in` file match edx-platform.
[ ] New requirements are in the right place (`base.in` if only used in enterprise; in the correct `platform-****.in` files if they're hosted in edx-platform)
[ ] Regenerate requirements with `make upgrade && make requirements` (and make sure to fix any errors).
*DO NOT* just add dependencies to `requirements/*.txt` files.
[ ] Called `make static` for webpack bundling if any static content was updated.
[ ] All reviewers approved
[ ] CI build is green
[ ] Version bumped
[ ] Changelog record added
[ ] Documentation updated (not only docstrings)
[ ] Commits are (reasonably) squashed
[ ] Translations are updated
[ ] PR author is listed in AUTHORS
[ ] Create a tag
[ ] Check new version is pushed to PyPi after tag-triggered build is finished.
[ ] Delete working branch (if not needed anymore)
[ ] edx-platform PR (be sure to include edx-platform requirements upgrades that were present in this PR)
*Author concerns:* List any concerns about this PR - inelegant
solutions, hacks, quick-and-dirty implementations, concerns about