Don't build the embedded stdlib or copy the trunk SwiftBridging header on Android CI

[finagolfin]

The Android CI is broken right now only because we're building the embedded stdlib unnecessarily, and that is currently broken on most linux toolchain CI, swiftlang/swift#89753. Disable it as we just throw out the results anyway.

Let me test this locally and it should be ready to go.

[DougGregor]

I think swiftlang/swift#89753 will unbreak the CI. My other PR doesn't have this fix.

[finagolfin]

I didn't even really notice we're building embedded till now, so it was pretty stable, 👍 just a waste to keep building it and then throwing it out. If we ever ship an embedded subset for Android, we'll enable this again.

[finagolfin]

Alright, worked fine locally, ready for review.

[finagolfin]

Added another commit to fix a CI failure when bundling, ready to go in, @justice-adams-apple.

[finagolfin]

Updated the bridging fix so it should only affect trunk, where this header was moved, swiftlang/swift#88748.

[finagolfin]

@shahmishal, this will fix the Android CI, ready to go.

[finagolfin]

Noticed that this would likely still break for the less commonly-run trunk PR CI, so updated with a fix for that too.

[DougGregor]

I want to poke at the "why?" here a little more. Embedded can be useful even for non-embedded targets because it doesn't require a runtime underneath, so you get independent binaries with smaller code size. I think Android users can benefit from that as well.

[finagolfin]

Sure, the problem is that nobody that I know of has gotten the Embedded subset compiled for Android, so the flag that would enable it is disabled by default and isn't wired up to build for Android anyway. However, since this --build-embedded-stdlib flag is enabled by default, we unnecessarily build the Embedded subset for linux/glibc alone on the Android CI, only to throw it out when creating the final Android bundle. All this pull does is stop wasting time building that linux/glibc Embedded stdlib on the Android CI.

As for getting the Embedded subset for Android going, there was broad agreement that it would be useful when the @swiftlang/android-workgroup discussed it a couple times last year, but nobody has stepped up to build it, or seemingly even tried to, as nobody brought it up this year.

I think we all agree that we'd like to have it, but nobody has stepped up to provide it, while this pull has no effect on Embedded Android.

[finagolfin]

In case it is unclear what I'm talking about, take a look at the failing build command in my first link in the OP, where the Embedded stdlib for linux-gnu was failing. We never built the Embedded stdlib for Android on the Android CI, so this pull simply disables building that linux-gnu Embedded stdlib alone.

[shahmishal]

Going to merge this to unblock Android CI.