LP#1749475 Rethink double-duty of SendEmail reactor

LP#1749475 Rethink double-duty of SendEmail reactor

Previously, we were trying to use the same reactor, SendEmail to both
generate email previews and also to generate and send emails.  This
behavior was meant to be controlled via $user_data.

This plan is problematic, particularly for grouped events.  It is
possible for events processed by the same hook/definition to have
user_data specifying different behavior, but then for the these events
to be grouped and processed together, creating a random outcome.

We start to see this issue already in our attempts to process $user_data
safely.  We notice this variable can be either an array for grouped
events, or a hash for ungrouped, or empty for cases where it isn't
required.  We could work around that situation with layers of error
checking, but still would end up with an arbitrary value.

Since very little of SendEmail is needed to actual generate the preview,
perhaps it makes the most sense, and is more clear, if we have a
separate reactor for doing the previews.  This commit does that.

Unfortunately, in doing so, we expose another weakness; event
definitions cannot share a template.  If we want the old hook to keep
functioning, we need to duplicate the new template in the old hook and
create an entirely new "preview" hook.  This invites maintenance
problems, but still better than predictability problems.  However, in
this case, we'll just overwrite the old hook, then emulate its behavior
at the API layer.

Signed-off-by: Dan Wells <dbw2@calvin.edu>