Raise on a field of a null object, interpreted and compiled

[Tutez64]

Reading a field of a null object answered null instead of raising, in both modes:

var h:HostBase = null;
h.kept;     // null, interpreted and compiled
h.scaled;   // null, getter never reached
h.kept = 1; // raised interpreted, did nothing compiled

• Interpreter. resolveField walks a.b.c segment by segment and treats a null got as a path still being resolved. After a variable, a call or a field that held null, the next segment was looked up as the type h.kept, found nothing, and the chain answered null. It now tracks whether got holds a value; a null value followed by a field raises EInvalidAccess, or answers null for ?.. Paths that are still types or packages (haxe.ds.Option.None) are unchanged.
• cppia. A host field read by name went through Reflect.getProperty, which answers null for a null object, and a write through Reflect.setProperty, which does nothing. Both now go through a small runtime helper, hxscript.runtime.Fields, which raises the interpreter's Invalid access to field <f> before delegating to Reflect. Reads on a live object are unchanged.

Three corpus cases (host field read, host property read, host field write on null). Before this change the read cases answered null in every column. With it, eval-interp, hxcpp-interp, hxcpp-cppia and hxcpp-cppia-jit all answer Invalid access to field kept / scaled. Corpus totals: 348 ok / 5 threw on the hxcpp columns; eval-interp also has the pre-existing killed on "an abstract Map through its alias" (Instance prototype not found: haxe.ds.Map). test/run.sh eval cpp: 421 / 421 / 440 passed. HashLink not run.

🤖 Generated with Claude Code

[MeguminBOT]

Reproduced: a read through null answers null in both modes, and a compiled write does
nothing. Raising is what Haxe and hscript do, so the direction is right. The trouble is that
scripts can rely on today's behaviour, most visibly as a null check one level too deep:

if (level.player.sprite != null) ... // level.player is still null here

That runs today and throws with this PR. On eval, h.kept == null, if (h.kept != null),
h.a.b, a null static's field and f().x all go from null to an error. Nothing that works
today may break, so could you put the raise behind a switch that is off by default, a Config flag
like strictAccess or a define, so a host opts in?

Two smaller things while you're there:

• The error is EInvalidAccess, whose hint says the field "exists but is not visible from a
  script ... A private member is only reachable from inside the type that declares it". For a
  null object that sends people the wrong way; the null case wants its own message.
• HashLink's compiled code isn't covered: the hl-bytecode column answers 0 for both reads and
  Null access for the write, before and after. Fine to leave for later, but worth saying in the
  description, which says "interpreted and compiled".

[Tutez64]

Done in 91c0d72 (on top of the original commit, and the branch is rebased on main):

• The raise is behind Config.strictNullAccess, off by default. Off, reads answer null and compiled writes do nothing, as before. The flag is read at the access in both modes rather than when compiling.
• The null case has its own ENullAccess: Null access to field f, with a hint about the null object. The interpreter's existing raises on a call or write through null now use it as well, so their message changes, not whether they raise.