Email Aggregation

I'm submitting this PR as I'd like some feedback if this is going in the right direction.
I've hooked up email aggregation for the content activities and tests.

The following is functional (albeit a bit rough):
 * Parsing and running Trimpath templates
 * Translating strings based on UI bundles
 * Aggregating activities in email streams
 * Scheduling (=bucketing in code) users for email delivery
 * Pushing out HTML email
    * Gmail: ![Gmail](http://cl.ly/image/3G0R3f0E350j/Screen%20Shot%202014-04-04%20at%2010.36.49.png)
    * Mail.app: ![Mail.app](http://cl.ly/image/2N2Z1V1p3R0b/Screen%20Shot%202014-04-04%20at%2010.32.14.png)


I'd like to get some feedback on the following things:
 * Does that scheduler/bucketing logic seem right? I copied most of the interval stuff straight from the aggregator as I assumed the email publisher would be doing a similar thing. I still need to add in daily collections, but I was thinking of just getting the current time and check if this was the right interval to send out the daily aggregates.
 * By reading the UI bundles and templates in the backend, the two repositories are now even more tightly linked. Is this OK? I've tried to keep most of the coupling local to the oae-ui bundle, but obviously it spills out in a couple of places. (I've out-scoped backend i18n bundles for now, to keep the size of the end PR a bit manageable)

(note that this depends on my activity aggregator reset PR)
This `OaeUtil.getNumberParam` no longer applies a minimum or maximum because it is caught earlier and set to the default if it violates the bounds.

My initial expectation on this was that if it was below the minimum. If it was above the maximum it would become the maximum just how `OaeUtil.getNumberParam` handles it out of the box. If the polling frequency chosen was not the same as the configured, then there would be a warning.