Adds composite build support for AztecEditor-Android

[oguzkocer]

This PR adds composite build support for AztecEditor-Android. It works exactly the same way as other composite builds, so there is not too much to explain. The only thing to be aware of is that even if the modules of this library were to be added as a dependency to one of the dependencies of WPAndroid (a dependency of react-native-aztec for example instead of directly being added) the composite build would still work. This is the case for every other composite build as well, but it's more important to be aware of for this project as explained below.

There was an interesting decision to be made here about how to setup composite build for this project, because the main client for the library is actually react-native-aztec however it's also used for the classic editor in WPAndroid. I opted for the simplest solution right now, as this is very familiar for developers and how it works will be clear to everyone who uses it.

The main setback of this approach is that react-native-aztec or react-native-editor can't directly use the composite build setup. (not without using it in WPAndroid) However, if we were to go for a solution to support that, it'd not only be harder to setup, but more importantly it'd also require some understanding or guessing by developers on how the dependency resolution will work for each project. If a developer forgets to turn off composite build at a library level, it'll also be a lot harder for #platform9 to help the developer when they are having build issues. So, I think this is a good start and we can re-visit it once developers get a chance to use it and report back on their needs.

To test:

1. Copy local-builds.gradle-example as local-builds.gradle
2. Uncomment and update localAztecAndroidPath to reflect your local path
3. Go to your local copy of your AztecEditor-Android and checkout this PR which is a requirement
4. Gradle sync in Android Studio which should bring up the project
5. Make a change in AztecAttributes - For example, you can add an isNotEmpty() method
6. Call that method in MetadataUtils and verify that the project builds

Test steps (5) & (6) are mostly for demonstration purposes.

Another test for the curious is to create a Gradle scan for example by running ./gradlew assembleWordPressVanillaDebug --scan, going into the Dependencies section and searching for aztec to verify the dependencies were resolved as the local module. Here is an example scan.

Regression Notes

1. Potential unintended areas of impact
   N/A - because this change can't have any impact on the CI builds as the composite builds are ignore

2. What I did to test those areas of impact (or what existing automated tests I relied on)
   N/A

3. What automated tests I added (or what prevented me from doing so)
   N/A

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[peril-wordpress-mobile]

You can trigger optional UI/connected tests for these changes by visiting CircleCI here.

[peril-wordpress-mobile]

You can test the changes on this Pull Request by downloading the APKs:

• Jetpack-pr-15432-build-116265.apk
• WordPress-pr-15432-build-116265.apk

[mchowning]

Everything is working as expected building both with the composite build and building from the AztecEditor-Android artifact. Once we merge the updates to Aztec-Android, we should probably update the artifact versions both here and in Gutenberg, but I don't see any reason we can't do that in a follow-up PR.

Thanks so much Oguz! 🙇