Feature/860 too many batch jobs

@davidhabib, would you please verify I have implemented everything we discussed yesterday:

- New schedulable (UTIL_MasterSchedulable) and interface (UTIL_MasterSchedulableHelper.UTIL_IRecurring)

- Stop using the old schedulable (UTIL_GlobalSchedulable) and interface (UTIL_IScheduled) and revert them back to their original form

- The only thing then new schedulable does is calling a class (UTIL_MasterSchedulableHelper) dynamically. This class does the actual work

- The new interface is NOT global(as we don't expect users to implement it)

- Post install script deletes any entries in the Schedulable__c table before populating it
(in case the user had the old classes in it). This means that every time the user visits
the settings page the table will be cleaned up and re-populated. Is this reasonable?

- The post install script will also abort the schedulables from the old NPSP packages.

- The uninstall script will abort any schedule job named as the old schedulable or the new ones.

We only have 6 jobs, and each run of the schedulable will run the max number of possible jobs (5 for batches). Since all our jobs are batches this means that the schedulable would be done if it run twice (5 run in the first pass, 1 in the second). However, it's possible that the user also has his own batches running around the same time. To cover for that, we run it 3 times. 

Initially, I had it running every hour. This way we are very certain it's able to run all the jobs. But Nick and Jason pointed out that this might slow down the performance of the application during business hours.