MacroApi cleanup for Haxe 5

[Simn]

Still some TODOs.

Closes #11431

[back2dos]

Since adding optional fields always incurs a marginal risk for breaking user code, might I use this opportunity to request also adding the positions of other names currently not exposed?

1. The position of the type name in BaseType and TypeDefinition.
2. The position of the field name in Field, ObjectField, EnumField and ClassField.

I see that some of these are already encoded in an unspecified name_pos (i.e. in ObjectField and EnumField as far as I can tell), but it would be nice to have proper access and generally be able to define / refer to finer grained positions for the sake of not coloring everything red.

FWIW I think in the types from haxe.macro.Type it could even be non-optional, because to the best of my knowledge constructing types by hand is not really a thing.

[Simn]

I'll have to check all this again, I thought this name_pos business was mostly for enum instances, where we can't access the value from Haxe anyway. But yes I'd like to clean all this up and provide all the information to macros.

[Simn]

@yuxiaomao Could you check this one too? Thanks!

[yuxiaomao]

It didn't break anything as far as I see, however in one of the projects I'm getting a warning many times (60+) at the same location in hxbit (https://github.com/HeapsIO/hxbit/blob/010d65702548fb2547cc7f6113910fcef4f68731/hxbit/Macros.hx#L561 at hxbit.Serializable.SerializableEnum<$et>):

`@:extern` is deprecated in favor of `extern`

Which is not the case with current development branch (with development, there is no warning at all). I'm not familiar with macro nor hxbit, and with -D dump I can't find any occurrences of @:extern, so I'm confused :<
In the code of hxbit/Macros.hx there is some meta : [{name:":extern",pos:pos}], so I think it's expected and this PR just makes it visible.

[Simn]

This could come from something that used to have null_pos now having a proper position. Although it's not immediately clear to me why all positions would point to the same reification location. Still this is likely something to fix in the macro, as you say.