Reduce number of tables

@heddn I believe we don't want one great table, here are some of my thoughts as to why we want the codes pools as seperate tables.

• A code pool might contain a list of prospect emails, another pool might have 11 alphanumeric characters, and so on with custom validation or data. So keeping these in different tables should help keep the pools clean with valid data.
• Table locking would be less prone in separate tables, as well as indexing smaller vs very large table

@heddn @vijaycs85
After reviewing this some more we have decided that we will want to make bundles of codes pools. Each Bundle would be stored as a single large table and be able to reference it's own sources. The sources could have specific constraints which will allow for handling unique codes uploaded on a per bundle level table, as well as constraints on the source of the pool data. This way we'll be able to have a more reusable codes pool module.

ie. A Codes pool could be used to dispense codes, or simple to store codes, prospect emails, phone numbers, etc for use in granting access or verification method for a tool.

In having a large table per bundle we will solve the issue of creating a new table for each code collection, as we will only create a new table on the bundle level.