Avoid creating TAnons from object declarations if we have an expected type

[Simn]

I saw in the hxb writer that we were dealing with hundreds of TAnons that should really be haxe.PosInfos. Anons are difficult to handle for a binary interface because we have to identify them properly, and doing so is not particularly pleasant

A large portion of them come from object declaration typing against an expected type, which results in something like [ObjectDecl:{ methodName : String, lineNumber : Int, fileName : String, className : String }] in the typed AST. With this PR, it emits [ObjectDecl:haxe.PosInfos] instead.

This cuts the amount of generated anons in our unit tests roughly in half, from 1700 to 800. It's still a rather high number that I want to investigate, but I think some of it comes from macro reification not creating objects against an explicit type.

Right now this doesn't quite work yet on HL:

 ERROR  src/unit/TestBasetypes.hx:214: characters 38-44

 214 |   var k = Lambda.array( { iterator : h.keys } );
     |                                      ^^^^^^
     | Don't know how to cast ():virtual(hasNext:method:():bool,next:method:():String) to method:():virtual(hasNext:method:():bool,next:method:():String)

The dump diff looks like what I'd expect:

I don't know why genhl is offended by that because its to_type seems to be recursing upon typedefs, so I must be missing something else here.

[Simn]

@yuxiaomao Could you look into the HL failure some time?

[Simn]

I'm avoiding the issue for now, but this isn't a good solution. Yuxiao identified the core problem which we can reproduce from this simple code:

function array(it:Iterable<String>) {}

function main() {
	array({iterator: null});
}

The issue is that the TObjectDecl is now typed as Iterable, and its function iterator is a Method while with pure anons it would be a Var. The HL generator tries to set the object field, but that doesn't work if the field comes out as HMethod.

I don't know what the correct solution here is though.