* "Reland Clang 11, roll buildroot to 1bc40a5f916adb93d87e2a2230a0ec43db876c1c, take 4 (#17467)" (#17482)"

This reverts commit 8166a91b.

* format code

* Roll buildroot to 3a27de1c5bb0f50be7d3efe3e00de4f6068c9f30

There is no ability to compile shaders online and cache those binaries when
using the Metal backend. SkSL caching must always be used.

* Initialize locale from FlutterEngine

Started clearing out the semantics information in Dart as well as deleting the AccessibilityBridge. (#17433)

Fixes https://github.com/flutter/flutter/issues/18208. All Metal for iOS related work items described in https://github.com/orgs/flutter/projects/5 have been completed.

If the application says there is a new texture but does not provide one, reuse the last texture. (#17437)

This matches the behavior of the OpenGL backend.

The following issues have been filed to track the handling of these enum values:

* Handle the UITouchTypeIndirectPointer enum value. https://github.com/flutter/flutter/issues/53696
* Handle the UITouchPhaseRegion enum values. https://github.com/flutter/flutter/issues/53695

No change in functionality. Only makes the iOS engine build on the latest
versions of Xcode and iOS SDK. The enum values cannot be used with the
API_AVAILABLE macro because the buildbots have not been updated yet.

This PR touches variable names, class names, and file names so it's significantly more risky than its predecessor https://github.com/flutter/engine/pull/17329

Due to file name changes, this PR is expected to change the license files.

We haven't rename `shell/gpu` to `shell/raster` yet. It should be optional but I think it's better to have `raster_surface_software.cc` than `gpu_surface_software.cc`.

Fix problem that using multi-engines, sometimes OpenGL would crash be cause of invalid EAGLContext (#17366)

1. Simple "GPU thread" to "raster thread" replacement.

2. Regex replace "GPU([\n\r\s]+//+ thread)" with "raster$1".

3. Regex replace "// gpu$" with "// raster".

4. Simple test change.

5. Run ci/format.sh

Removed a text input trait that causes VoiceOver to be incorrect when tapping a text input. (#17203)

This reverts commit 2627634b.

Fixes https://github.com/flutter/flutter/issues/52356

This moves the Metal `GrContext` creation utilities from `GPUSurfaceMetal` into
a separate `IOSContext` object subclass. An analogue of this object was used in
the GL regime for the management of onscreen and offscreen contexts that were
not tied to the lifecycle of the `GPUSurface`. This pattern has now been
generalized for use with all backends that need a resource context
(`IOSContextGL` and `IOContextMetal`).

The platform views controller management in the `ExternalViewEmbedder` interface
implementation was repeated three times for [Metal][metal], [OpenGL](opengl) and
[Software](software) rendering. This repetition has been removed and a single
implementation present in the base `IOSSurface` and used on all platforms.
Addition of new client rendering APIs should not affect how the engine renders
into the platform view interleaving levels.

All rendering API selection logic has been moved into a single set of utilities
in `rendering_api_selection.h`. This enables the removal of a lot of code blocks
guarded by `FLUTTER_SHELL_ENABLE_METAL`. The remaining uses of this will be
removed when unified builds are enabled.

The Metal backend now also adds traces similar to the GL backend.

The `IOGLContext` has been renamed to `IOContextGL` to be more in line with the
convention used in this library.

Fixes https://github.com/flutter/flutter/issues/41827
Adds https://github.com/flutter/flutter/issues/52150

[metal]: https://github.com/flutter/engine/blob/1194ba2b218706a201c5d2c5325b55a5932546c5/shell/platform/darwin/ios/ios_surface_metal.mm#L55
[opengl]: https://github.com/flutter/engine/blob/1194ba2b218706a201c5d2c5325b55a5932546c5/shell/platform/darwin/ios/ios_surface_gl.mm#L95
[software]: https://github.com/flutter/engine/blob/1194ba2b218706a201c5d2c5325b55a5932546c5/shell/platform/darwin/ios/ios_surface_software.mm#L146

Co-authored-by: NAaron Clarke <aaclarke@google.com>

Chrome Trace viewer treats events labeled "VSYNC" as special and highlights them (when the "Highlight Vsync" checkbox is enabled). Ideally VSYNC events are generated by the host system at their source. System VSYNC events are indeed present in full-system systraces. Flutter-level traces (as seen in Observatory/Flutter devtools) do not contain the system VSYNC events, so we rely on the engine to generate them (as close to where they would be generated by the system ideally).

Currently the common (platform-independent code) generates VSYNC events at the time when the UI thread starts processing a frame. This has two drawbacks:
1. The traces are generated with a delay (we wait for the callback to be have been scheduled on the UI thread instead of tracing as soon as the system notified us.
2. When inspecting system-wide traces we'll have both the system and the Flutter app (or potentially multiple Flutter apps) generate VSYNC events at the same time. This confuses both the developers and the trace viewer.

This change moves the VSYNC event generation to the platform-specific embedder implementations:
1. On Android/iOS we always generate the VSYNC event since Android/iOS developers use Flutter tools to debug the apps.
2. On Fuchsia we do not generate VSYNC events since the systraces always contain them.
3. In the Embedder wrapper we don not generate VSYNC events and rely on the actual embedder to do this in a way appropriate for the target system.

Make sure that a text range at the end of the string is still valid.

This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.