Previous versions of Civi sometimes generated URLs for contact-images with incorrect `&mime-type` values:

http://dmaster.bknix:8001/civicrm/file?reset=1&filename=Hello_cca4153cb14beab37c68ab7f07162425.jpg&mime-type=image/jpg

The recent security update will generate an error if the mime-type is incorrect, so this patch relaxes it
to allow the old links to continue working.

Add whitelist back in and validate extension of file is permtted for the mime-type supplied and use mime-type from db if supplied with an fid and eid

Switch to different libary that is php5.6 compatable

Strength mime checking by comparing mime-type to the file path mime-type if we have entity_id and file id otherwise only permit image mime_types to be accepted if going via the filename route

Ensure mimetype is set in the case where we are passing it through and its valid

Remove Whitelisting of mime-types as not useful and only check mime-types if we have had one passed in

Fix Rule checking and add a unit test

Add in unit test on building country_id options too

Add in a unit test for building county options with a state_province_id filter

Overview
----------------------------------------
Set limit for activity_contact retrieval to 0, allowing to retrieve more than 25 activity contacts when rendering the first 25 activities on the activity contact tab

Before
----------------------------------------
![before](https://user-images.githubusercontent.com/336308/57439801-e42a0580-729a-11e9-80a1-45df93d0c5eb.jpg)

After
----------------------------------------
![after](https://user-images.githubusercontent.com/336308/57439960-39fead80-729b-11e9-9701-acd79ff73497.jpg)

Technical Details
----------------------------------------
This moves the logic for retrieving the target contacts back into the getActivities function. We are stil not wanting to bypass the ACLs so still using the
api but strictly limiting the number of contacts we retrieve (at the cost of extra queries, but cheap ones).

Some tests added on the Bulk Mail activity.

Comments
----------------------------------------

#956 Fix hard breakage in find participants form when you do a filter on one event and n participant statues

Per https://github.com/civicrm/civicrm-core/pull/13470 custom fields are
inconsistently copied where copying entities. This makes the code from
BAO_Event called from the genericCopy function.

I did a bit of an audit and the places where this is currently called from don't appear
to call the copyGeneric function with the 'custom' param that would have activated the old
code. I also consistently removed the & when it was being called so I could take it
out of the signature.

The original PR handled tags as well, but not in a generic way. I've left that out of scope
but the test is present, commented out, so it would be easy enough to revist

For some obscure reason the relationsip BAO was forcing the is_active field
to default to 0 even though the schema sets a more sensible default of 1.

At the moment activities are created when using the additional payment form but not the UI.
This needs cleaning up & this takes the first step by adding testing & slightly
simplifying where decisions are made about variables (assign title directly rather than component
just to assign title deeper down

Resolve #931 by not doing translation on the query if field exists during the upgrade process

Dates back to https://github.com/civicrm/civicrm-core/commit/eda34f9b15c494715e8fc54f09b5ea4308d16b17#diff-8041069091a94b730ff8ad60bdd24042R70
(Mar 2018).

To recreate do a first name search & create a smart group from it