core: Simplify & support non-ident common strings

[kjarosh]

This PR replaces the define_common_strings! macro-rules with a procedural macro that automatically generates field names from the provided byte string literals. This reduces duplication in common.rs by removing the need to manually specify str_ prefixes for every common string.

After refactoring define_common_strings! to a proc macro, we can escape non-ident characters in strings and generate identifiers dynamically. This makes it possible to use any string as common string.

Finally, the PR adds more common strings that weren't added previously due to the fact that common strings didn't support non-ident strings.

[moulins]

I'm not a fan of how this moves the actual struct CommonStrings definition outside of the avm_string/common.rs file...
Instead, what if common_string_to_ident was directly exposed as a proc-macro? Then define_common_strings can stay as a normal decl-macro, and include things like common_string_to_ident!($field): AvmString<'gc> in its expansion.

[kjarosh]

I'm not a fan of how this moves the actual struct CommonStrings definition outside of the avm_string/common.rs file

Doesn't it make more sense for the structure to be defined in the same file it's used? I think it makes more sense for istr! to be in the same place as define_common_strings!.

[moulins]

Well, ideally istr! would also be a decl-macro defined in terms of common_string_to_ident!, but this can't be done easily as the short form (istr!("foo")) isn't hygienic.

Doesn't it make more sense for the structure to be defined in the same file it's used?

With your changes, the declaration also get split: e.g. define_common_strings! still depends on having ASCII_CHARS_LEN and ASCII_CHARS in scope, which makes understanding how the code works much more difficult imho.

Sure, this could be fixed by moving the entirety of the common.rs file inside the proc-macro, but that would makes thing even more opaque to the average reader (and would probably worsen IDE experience).

[kjarosh]

Sure, this could be fixed by moving the entirety of the common.rs file inside the proc-macro, but that would makes thing even more opaque to the average reader

I'm not convinced that's the case, the structure and its usage will be in the same file anyway. I think we can just more the existing code as-is before the struct. Doesn't make sense to make the implementation detail public. Placing definitions of istr and define_common_strings in completely different crates would be more misleading.

(and would probably worsen IDE experience).

In what way? I didn't notice anything particularly bad.

[moulins]

A "go-to" definition on the CommonStrings type won't bring anything useful: it'll point to the define_common_strings! { ... } macro call, and the actual type definition (including its constructor) will be completely hidden inside the proc-macro code.