Incorrect resource merging logic when handling conflicts

Description :
Our large project include duplicated android resources. We recently hit a bug when our developers introduced a dependency to a new third party library, which contains an android resource with the same name as one used in our top-level target. This is due to the fact the old APPT1 behavior is currently preserved, and the defined resources in the list provided to Aapt2ResourcePackagingAction 'wins'. The expectation is that the closest value defined from the app wins.

The project below exemplify this (bogus) behavior : `app` defines resource `app_name` and `app_name2` (with same value), depends directly (or transitively) on library `lib`, which defines also `app_name`. In the final APK, `app_name` has the value from `lib`.

This is problematic for projects tolerating duplicated resource, as, even with warnings, breaks can easily be introduced as any code change or third party library bump could possibly overwrite the value defined in top level target.

The workaround we're using is to reverse the input order in Aapt2ResourcePackagingAction.

Repro :
1. clone https://github.com/oliviernotteghem/rules_android/tree/repro_merge_issue branch (or simply cherry-pick https://github.com/oliviernotteghem/rules_android/commit/0f36bf11728f6e9ba05453d141b2f6da3316fba3)
2. bazel build java/com/basicapp:basic_app
3. visualize output APK in android studio :