DRYD-2100: Configure legacy trash implementation

[mikejritter]

What does this do?
Adds configuration to use Nuxeo's legacy trash implemenation

Why are we doing this? (with JIRA link)
Jira: https://collectionspace.atlassian.net/browse/DRYD-2100

The new TrashService and implementation are not accounted for anywhere in our codebase, so trashed documents end up coming back in API responses and other places. Before we potentially migrate to the new implementation, we can add some configuration to enable the legacy implementation which allows us to make fewer changes at the moment.

How should this be tested? Do these changes have associated tests?

• Rebuild CollectionSpace with the upgrade branches in the services and application repositories
• Start CollectionSpace
• Create and delete a record or two, or delete some other records (e.g. vocabulary terms)
• Verify that the deleted items do not show up in the interface
• Check the hierarchy table and misc table to see that the names are not clobbered, e.g.

nuxeo_default=# select hierarchy.name, hierarchy.primarytype, misc.lifecyclestate from hierarchy join misc on hierarchy.id = misc.id where misc.lifecyclestate = 'deleted';
          name           |   primarytype    | lifecyclestate
-------------------------+------------------+----------------
 37621cd1-66ab-48c6-ad31 | Vocabularyitem   | deleted
 436bec73-0d34-4040-84cd | Vocabularyitem   | deleted
 d7c01623-ff79-44f5-b8f8 | CollectionObject | deleted
 d42f07c6-d6db-4b39-96b0 | Vocabularyitem   | deleted

Dependencies for merging? Releasing to production?
We should move away from the 9.10-HF30 folder for configuration, though we have another ticket to handle build changes already.

Has the application documentation been updated for these changes?
No. This is something that we should look at adding to the developer docs.

Did someone actually run this code to verify it works?
@mikejritter has been testing locally

Have any new security vulnerabilities been handled?
n/a