Replace basis-universal-rs with basisu_c_sys to improve basis universal support

[beicause]

Objective

Closes #23597

Solution

1. Add ASTC HDR to CompressedImageFormats, and ktx2 loader.
2. Remove basis-universal crate and .basis format support from bevy_image.
3. Replace CompressedImageSaver with BasisuSaver/BasisUniversalProcessorPlugin asset processor. Enable basis_universal feature to enable loading support. Enable basis_universal_saver feature to enable saver and asset processor.

Testing

basisu_c_sys is tested in https://github.com/beicause/bevy_basisu_loader.

Run with --features basis_universal_saver,asset_processor:

//! Displays a single [`Sprite`], created from an image.

use bevy::image::BasisUniversalProcessorPlugin;
use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins((
            DefaultPlugins
                .set(bevy::log::LogPlugin {
                    filter: "bevy_image=debug,bevy_asset=debug,wgpu=warn".to_string(),
                    ..Default::default()
                })
                .set(AssetPlugin {
                    mode: AssetMode::Processed,
                    ..Default::default()
                }),
            BasisUniversalProcessorPlugin::default(),
        ))
        .add_systems(Startup, setup)
        .run();
}

fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
    commands.spawn(Camera2d);

    commands.spawn(Sprite::from_image(
        asset_server.load("branding/bevy_bird_dark.png"),
    ));
}

[beicause]

Another option is checking "KTXwriter" key in ktx2 file so that we can support basisu in ktx2_buffer_to_image and don't need a new crate.

Update: Done.

[ChristopherBiscardi]

This introduces a dependency on basisu_c_sys, which has only existed for 5 days. Why isn't that also included here to be upstreamed? Do you plan on maintaining it moving forward?

How does this PR impact basisu support in Bevy? ex: does it work on wasm? The file extension required to use basisu is changed by this PR and .basis files seem unsupported. The new module could use documentation, especially since most users are unfamiliar with what basisu is, how to create the files, and what that means for platform support.

There don't seem to be any usage examples or tests. How should someone determine if this code works now and in the future?

[beicause]

basisu_c_sys depends on the cpp library and the wasm_bindgen bindings to emscripten's prebuilt wasm for web support, so yes.

It includes transcoding and encoding tests in my repository. I expect to maintain it, but I'm willing to transfer it to the bevy organization if bevy wants.

The lack of .basis support is because it's relatively outdated and not supported by the C API.

[atlv24]

@cwfitzgerald is working on a texture compression library, he may have something to say

[cwfitzgerald]

I don't have much too much of substance to add. I think having up to date bindings would be good and moving to standardized ktx2 files is an improvement over custom basis files. I do plan on adding basis support to ctt, likely through this set of crates, which @JMS55 will integrate with the bevy stack, but that's still a bit out and I'm not sure how that would relate to this PR as this seems to also have tools at runtime.

[alice-i-cecile]

Note: I've marked this as particularly controversial because it swaps our dependencies out. This is a classic supply chain threat model, so we need to have a careful plan here.

@beicause, this isn't personal to you; you've done fantastic work elsewhere and are rapidly building trust. It's just a matter of policy and best practices.

[beicause]

I do plan on adding basis support to ctt, likely through this set of crates, which @JMS55 will integrate with the bevy stack, but that's still a bit out and I'm not sure how that would relate to this PR as this seems to also have tools at runtime.

I know #23567 and from what I saw it's a processor for native gpu compressed formats.

I think basisu should be a separate processor as it has different encode params and needs runtime transcoding and wasm32-unknown-unknown shims. So this can be independent.

This introduces a dependency on basisu_c_sys, which has only existed for 5 days. Why isn't that also included here to be upstreamed?

+: I have worked on the basisu binding several months ago and basisu_c_sys is refactored from bevy_basisu_loader_sys. It should not be included here because it has cpp dependency and tens of MB of snapshot in tests.