dev/core#2800 Fix bounce processing to handle verp emails

dev/core#2800 Fix bounce processing to handle verp emails

This fixes 2 issues when combining bounce processing with verp emails

1) the emails being processed are being matched to email they come from -
ie the verp email. Hence the created activities are not linked to the
actual contact and instead create endless variants of the sender.
This happens with both the job.process_activities job and with
job.fetch_bounces with is_create_activities = TRUE.
This fix adapts the handling to identify verp emails (using existing regex)
and look up the contact ID from the mailing_event_queue. This is
used as the source (I didn't add a target or assignee at this stage cos
I wasn't sure if that was just data-cruft or useful stuff - but it would
be retrieved from the mailing)

2) this second one is a doozy & probably only showed up in tests because the
tests mostly cover obscure email formats. The create activities code does
a call to get the body and attachments using a function that looks like it
came from a tutorial on how to best use ezcmail. It seems to parse
all the email variants and attachments and, importantly, moves those attachments
to the civicrm files as part of creating the activity.

The code used to getBody() for bounces looks like it was ... written by us.
It does a subset of the processing in earlier call to get body and in
many of our test cases falls back on a blunt generateBody(). This call parses the
email, including the attachments, which are no longer there cos they got moved....
so it fatals.

I dug into the 2 functions and I feel pretty sure the bounce one doesn't add any
additional value but DOES have less capability than the other. So I removed that code,

Unfortunately the person received weird email from Exchange 2003 did not log
the headers https://issues.civicrm.org/jira/browse/CRM-9361 - but even if the
preferred version of the function doesn't parse that there is default text so
it won't fail & it seems like the risk of having a bit less info about an (untested)
obscure email bounce body is not that probematic