Don't use mode="merge" in filter.xml

### Expected Behaviour
Any rules in the filter.xml files using `mode="merge"` should instead be using `mode="merge_properties"`. Per [Jackrabbit FileVault's documentation](https://jackrabbit.apache.org/filevault/filter.html#filter-elements), the `merge` property is deprecated in favor of `merge_properties` as `merge` is "not handled consistently".

### Actual Behaviour
Currently, the generated filter.xml files are using `mode="merge"`

### Reproduce Scenario (including but not limited to)
Create a new AEM project from aem-project-archetype, observe various rules in filter.xml (most notably in ui.content) are using `mode="merge"`

We have observed severe content/data loss in an AEM 6.5+ environment as a result of using this `merge` property that comes with the `aem-project-archetype`. Specifically during the scenario where we have been continuously deploying a `1.0.0-SNAPSHOT` maven version of our codebase (all bundles have same version including ui.content bundle), then once we deployed a maven release version of the codebase (`1.0.0`), Jackrabbit FileVault reverted a significant amount of content in the production environment resulting in large content loss. It is believed that the existence of `mode="merge"`within our ui.content/filter.xml for the common content paths such as /conf/mysite and /content/mysite caused these paths to be impacted in the production instance upon bundle installation.

#### Platform and Version
AEM 6.5+ & AEMaaCS

#### Sample Code that illustrates the problem
https://github.com/adobe/aem-project-archetype/blob/develop/src/main/archetype/ui.content/src/main/content/META-INF/vault/filter.xml

Inspect src/main/archetype/ui.content/src/main/content/META-INF/vault/filter.xml, linked in the issue, and find each rule using mode="merge". Replace those values with mode="merge_properties", then verify the generated filter.xml no longer contains the deprecated mode.

Written by the indexing model from the issue text.