Feature Request: Native Support for Huawei HarmonyOS

## What problem does this solve or what need does it fill?

Bevy is a modern, data-driven Rust game engine renowned for its high performance and cross-platform capabilities, currently supporting Windows, macOS, Linux, WebAssembly, Android, and iOS. However, with Huawei HarmonyOS rapidly expanding its ecosystem across smart devices—including smartphones, smart screens, wearables, and automotive systems—developers are increasingly seeking to deploy Bevy-built 2D/3D applications natively on these platforms. The absence of official HarmonyOS support forces developers to rely on unstable workarounds, Android compatibility layers, or abandon Bevy entirely, undermining its potential as a truly universal engine. Adding native HarmonyOS support will bridge this critical gap and position Bevy as the first mainstream Rust engine to fully embrace Huawei’s next-generation distributed OS.

## What solution would you like?

We propose adding native HarmonyOS backend support to Bevy’s bevy_window and bevy_render modules, leveraging existing Android infrastructure for efficiency:

1‌: Integrate ArkUI via Rust FFI‌: Use HarmonyOS’s Ability and Surface APIs to manage window creation and rendering contexts.
2‌: Reuse Vulkan/OpenGL ES backend‌: Harmonize with Bevy’s existing Vulkan renderer, adapting only context initialization for HarmonyOS-specific GL/VK entry points.
3‌: Map input events‌: Translate touch, gesture, and remote control inputs into Bevy’s standardized Input system.
4‌: Add build target‌: Extend bevy build with --target harmonyos to generate .hap (HarmonyOS Ability Package) files automatically.
‌5: Provide example project‌: Ship a fully functional bevy-harmonyos-example demonstrating game deployment on HarmonyOS smartphones and smart displays.

This approach minimizes duplication by reusing Bevy’s proven Android porting patterns while enabling access to native HarmonyOS features like distributed rendering and multi-device synergy.

## What alternative(s) have you considered?

1‌: Android compatibility layer‌: While HarmonyOS can run some Android apps, it introduces performance overhead, limits hardware access, and blocks integration with native distributed capabilities.
‌2: WebAssembly deployment‌: Runs in HarmonyOS browsers but lacks low-level hardware access, suffers from performance penalties, and cannot support multi-screen coordination.
‌3: Community unofficial ports‌: Existing attempts lack maintenance, suffer from fragmentation, and are incompatible with official Bevy releases.

None of these alternatives deliver the performance, fidelity, or ecosystem alignment that native support provides.

## Additional context

1: Huawei has fully opened its DevEco Studio toolchain for Rust development as of HarmonyOS 4.0.
2: Key components like ArkUI and distributed task scheduling are now open-sourced, enabling direct integration.
3: Godot Engine has already implemented experimental HarmonyOS support in v4.3, proving technical feasibility.
4: Bevy’s successful Android and iOS integrations (bevy_android, bevy_ios) offer a clear architectural blueprint.
5: Official support would make Bevy the first major Rust game engine to support HarmonyOS, significantly boosting its adoption in IoT and smart device markets.

**NOTE: My English is terrible, so I used AI to write this sentence. Sorry.**

Start by reading the existing Android integration and the bevy_window and bevy_render modules mentioned in the issue. Determine how HarmonyOS window creation, rendering contexts, and input events could fit those paths, then assess the proposed --target harmonyos build flow and example project. Done means a supported native target with working packaging, rendering, input, and deployment coverage.

Written by the indexing model from the issue text.