search builder: respect "contact is trashed" field

in search builder, choose [any contact type] [contact is in trash] [=] [1/yes]
expected result: returns only contacts in trash.
actual result: ignores criteria and returns contacts not in trash.

there are a couple issues –

in our main BAO/Query.php file, we set a variable $onlyDeleted based on the presence of "deleted_contacts" parameter – and default to FALSE if the param is not present. but search builder passes the value as "contact_is_deleted" and so the value is overwritten by the $onlyDeleted param.

however – it's not simply a matter of setting that variable by the alternate name. in search builder, we don't want a universal $onlyDeleted param. the parameter has to be set based on the criteria grouping. for example, you can have one set that retrieves trashed households, with an OR join to orgs that are not trashed – in which case each set joined by OR must have it's own is_deleted value set. further – if a set does not explicitly set the contact is trashed field, we should imply is_deleted = 0, as is our standard pattern.

I've fixed it with the following patch – but am not crazy about it:
https://github.com/nysenate/Bluebird-CRM/commit/5e926361ae7e96d074ca36f91c36b2421faed258

what we do in the patch is before implementing the parent postProcess in builder, we check to see if the contact_is_deleted field exists. if it does, then we group the params by set so we can determine if any set does not have that field explicitly included. if it does not – we need to add it with a value of 0 so we exclude trashed. we then pass a value to the session that is retrieved by Query.php so that we set _skipDeleteClause = TRUE – which avoids the universal param and allows the param to be added on a per-builder-set basis. the session variable needs to then be re-set so that it doesn't affect others searches (e.g. Advanced Search). (this is the part I'm not crazy about)

it is working fine in my testing but deserves some review.