ci: move to macOS 13 runner

[Lyokone]

Description

Thanks to macOS 13 images we can also run macos ci on the latest version of Flutter.

• I've moved the performance tests on the main test package since it was requiring maintaining a separate CI for no particular reason (we still have firestore separated since it takes time to compile due to GRPC)
• Removed useless step of building an app before running e2e tests (e2e tests already build the app with integration_testing)
• Fixed the package name of cloud_firestore (was different between build.gradle, manifest and java file)
• Skip a test in Messaging since we are now using SDK 33+ to test (we need to integrate with patrol to be compatible with requesting permissions at runtime)
• Remove saving logs of adb logcat, create interferences on some firebase_crashlytics test for some reasons on SDK 33+
• Manually handle Android emulators instead of relying on the cirrus action since the macos 13 images come with Android SDK installed as default :)

Related Issues

Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR. Note that you'll have to prefix the issue numbers with flutter/flutter#.

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
• All existing and new tests are passing.
• I updated/added relevant documentation (doc comments with ///).
• The analyzer (melos run analyze) does not report any problems on my PR.
• I read and followed the Flutter Style Guide.
• I signed the CLA.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change.
• No, this is not a breaking change.

[mikehardy]

I am surprised this yields a positive result! Really cool if so.

What I observed on multiple runs where the AVD cache was pre-generated (before API33 at least...) was lower performance on the first run (obviously) but if the AVD cache was pushed on main branch only so it wasn't evicted from github's cache, subsequent runs on main and all PR branches were much faster as a performance benefit

What I further observed was that the emulator performs lots of "first run" type things on it's first boot, so when I gave the emulator time to do that during AVD cache generation - meaning it was already "warm" for cache hits, I actually had greater stability as well, since there were some "first run" type things that failed sometimes (Zygote initial memory setting, for instance, or just race conditions with test operations) that resulted in better AVD stability on cache-hit runs / less flakes, as a stability benefit

If your new CI AVD strategy results in similar or better performance and stability, I need to look at this in react-native-firebase