Remove create_enum and create_extensible_enum macros

[heaths]

LSP refactoring tools and LLMs have problems with the create_enum and create_extensible_enum macros because they aren't defined as enums e.g., Copilot will grep for "enum EnumName" and won't find it.

While the macros are handy, proc macros are just code generators. And we already will generate most of our code via Azure/typespect-rust. Thus, we should just expand the enums we have now in core and other hand-written files.

The emitter already has an issue to remove use of them: Azure/typespec-rust#611

And rather than create a proc macro as the original description here describes, as the discussion below points out: with all the "wrapping" of serde attributes we could do but probably shouldn't, we end up having to type 90% or more of the enum anyway e.g., the type declaration, the variants, serde attributes, other derives e.g., SafeDebug, etc. We could even mark the non-unknown variants as #[safe(true)] because they are defined values, but leave the whole type as unsafe so that the UnknownValue isn't traced by default.

And given the complexity of writing, debugging, and maintaining a proc macro, it's just not worth it for the last 10% or less when we already use a code emitter for more code.

[heaths]

In the meantime, I created a create_extensible_enum!() macro in #1852 as a stopgap solution for @jhendrixMSFT for the TypeSpec emitter.

[analogrelay]

I like #[variant(other)] and had a similar thought that we might want a way to support unknown values from the server.

Should we try to duplicate necessary serde attributes like rename_all? Off hand, that may be all we need.

If we're hand-implementing the serde traits, I think we would have to duplicate those attributes, since the #[serde] attribute is only in scope when using their derive macro. I believe rename_all would be sufficient, though we might need rename as well to handle irregular cases.

---

Since we're not actually deriving a trait, it might also be reasonable to use a general attribute macro, rather than a #[derive] macro. I don't mind using a #[derive] one if that's what feels easiest, but it might be a little confusing to someone reading the code.

[heaths]

Since we're not actually deriving a trait, it might also be reasonable to use a general attribute macro, rather than a #[derive] macro. I don't mind using a #[derive] one if that's what feels easiest, but it might be a little confusing to someone reading the code.

The goal is to create a derive macro, though, and specifically so we could have helper attributes; though, if we could easily enough still handle helper attributes to customize the enum or individual variants I'd still be open to that. Some earlier prototypes I couldn't make work but - especially back then - hadn't gotten my hands quite so dirty into TokenStreams as more recently.

And, yes, I'd want to support individual renames as well. I expect the emitter would use rename, in fact, because it's easier to just repeat a pattern; rename_all would be better for what little hand-written code I'd expect. Am I right, @jhendrixMSFT?

[jhendrixMSFT]

I expect the emitter would use rename, in fact, because it's easier to just repeat a pattern;

That's correct.

[analogrelay]

The goal is to create a derive macro, though, and specifically so we could have helper attributes; though, if we could easily enough still handle helper attributes to customize the enum or individual variants I'd still be open to that.

Ah yeah, if we need helper attributes, I agree a derive macro is likely the best option. With a plain attribute macro we could still support helper attributes, but we're entirely on our own to extract them from the TokenStream, which would be a lot of work.