Support ron format maps as assets

[MickHarrigan]

This is a Frankenstein way to force functionality with maps in ron to work with this library. This is due to #179.

Given what I needed this to be able to do it does that with only a minor modification required on the user side. That change is wrapping the {} in () first, but this may be able to be worked around as well.

Feel free to touch up or change anything within this, its very far from being published or merged as it is just a proof of concept for now.

[MickHarrigan]

Did more digging with this and with serde as a whole and from what I have been able to hack together, this isn't particularly easy to implement.

I did some testing with just serde and was only able to get a format that fit my needs partially. With just serde I was able to implement ron maps, lists, and regular structs as deserializable into

#[derive(Serialize, Deserialize, Debug)]
#[serde(untagged)]
enum Types {
    // individual types
    Image { path: String },
    Square { length: f32 },
    Sphere { radius: f32 },
    Data { data: String },
    Blank,

    // types for collections
    Map(HashMap<String, Types>),
    Vector(Vec<Types>),
}

This is so close to what I want, but I have been unable to get the conversion from just serde to everything that bevy_asset_loader requires. Even still, this format doesn't deserialize from exactly what I want (Which is that all the individual types are explicitly written in ron, but the map and vector are implied when deserialized).

Other than that issue, the code that I currently have provided on this PR has the issue that there are handles to each individual asset, as well as from the top level to the collection of lower assets. This means that having the top level does nothing but add complexity and useless bloat.

If somehow there is a way to get this to work such that the data can be defined in n levels of nested maps/arrays without having to directly specify them as such with a name, but leaving all the actual data fields to have it, that would be perfect. But until that comes I think this should at best be left at an idea and a draft if not closed altogether.

[NiklasEi]

I think you would need to split the tagged and untagged variants into different enums. In #151, untagged vectors are implemented using the latest main branch from ron.

[MickHarrigan]

I think you would need to split the tagged and untagged variants into different enums. In #151, untagged vectors are implemented using the latest main branch from ron.

Wow, not sure how I completely missed that branch and issue. I did a bit of messing with it and I did get a very very simple example working how I expected to have it work. I will keep working on it until I feel that it is of a good enough caliber to contribute to the branch anyways.