Include armv7 symbols in boringssl vendoring

[orobio]

Updates the BoringSSL vendoring to include armv7 specific symbols.

I had to do a work-around that specifically checks out the version of BoringSSL that is currently used. This was necessary due to that the very latest on their main branch doesn't work properly with the current vendoring script. I suggest to not merge this until the vendoring script is updated to work with the latest BoringSSL version again, then the work-around can be removed.

The armv7 build is done using the following container: orobio/swift-armv7-cross-bullseye:5.10
It was created from orobio/swift-armv7.

This container is hosted on my DockerHub account. Would that be acceptable, or would you prefer to host it yourself?

Most of this is new territory for me, so feel free to mention anything that can be improved.

[Lukasa]

Sorry for letting this languish!

@shahmishal is there any way we can get armv7 Swift images upstream?

[orobio]

Any news on this? It would be nice to finish this up in one way or another. Let me know if there’s anything I can do!

[xtremekforever]

Maybe we just need to generate a Swift 6.0.1 unofficial container for armv7 now? Well, there are a couple of blockers to generating an SDK as was suggested previously:

• I looked at using the swift-sdk-generator to create an SDK but it's simply not ready to be able to generate an SDK for armv7 in its current state. It will require some updates, such as supporting Debian 11 or 12 to grab armv7 debs to generate an SDK. Then, it would need to be able to somehow grab the armv7 build from "somewhere" (maybe locally) and put the files in the correct place. Right now the SDK generator places target .swiftmodules and libraries in the swift.xctoolchain directory, which is not quite right since they should go into the SDK directory for the target!!!
• I had been previously investigating adding support into swiftlang/swift to cross compile for armv7, but ran into quite a few issues and a Swift runtime that didn't actually work properly on the target. Since then this effort has been paused due to other commitments on my end.

However, if we can just use some of the existing swift-armv7 scripts to build Swift 6.0.1 and generate a container, would that be enough to at least get this done? It would be simple enough to update what we have working and generate something that could be used.