Abstract generate @:impliciteCast instead of cast in some situation, cause different behavior on HL

When working with `-D hl-check`, I saw the following situation generate `@:implicitCast` (`[Meta:String] :implicitCast` in dump). `@:implicitCast` is not parsed by HL, which cause a type mismatch on call to `.split` (Dynamic instead of String).
Simply separate the line in two will not remove such metadata, and the cast is done correctly.

I'm wondering if that's some abstract related issue? Because I didn't see other target parse `@:implicitCast` tag, and when checking with a larger codebase, `@:implicitCast` seems mostly generated with on a same type or with a `Null<>`.
Or maybe I'm missing something and it's better to fix it in HL?

```haxe
class Test {
public static function parse (json:String) {
var rawData: DataRaw = haxe.Json.parse(json);
var encoded = rawData.mappings.split(';'); // generate @:implicitCast instead of Cast before split
trace(encoded);
}

static function main() {
parse("{ \"mappings\" : \"some;thing\"}");
}
}

abstract DataRaw(haxe.DynamicAccess) to haxe.DynamicAccess {
public var mappings(get,never) : String;
inline function get_mappings() : String
return this.get('mappings');
}
```

Dump:
```haxe
[Var encoded<12356>(VUsedByTyper):Array]
[Call:Array]
[Field:(delimiter : String) -> Array]
[Meta:String]
:implicitCast
[Cast:Dynamic]
[Cast:Null]
[Call:Dynamic]
[Field:(o : Dynamic, field : String) -> Dynamic]
[TypeExpr Reflect:Class]
[FStatic:(o : Dynamic, field : String) -> Dynamic]
Reflect
field:(o : Dynamic, field : String) -> Dynamic
[Cast:Dynamic] [Cast:haxe.DynamicAccess] [Local rawData(12337):DataRaw:DataRaw]
[Const:String] "mappings"
[FInstance:(delimiter : String) -> Array]
String
split:(delimiter : String) -> Array
[Const:String] ";"
```

Start with the provided Haxe reproduction under -D hl-check and inspect the dump around [Meta:String] :implicitCast and the .split call. Compare the behavior with the HL target and the other targets mentioned; done means determining whether the compiler or HL should handle the metadata and preventing the reported type mismatch.

Written by the indexing model from the issue text.