Field hooks suppress useful errors about unknown IDs

[awelzel]

Forgot to use a ASN1:: prefix for a field with a hook and it took a bit to figure out the problem...

The crux is that when a "field hook" exists, the following useful/actionable error message:

[error] test.spicy:8:3: unknown ID 'ASN1Messup'
[error] spicy-driver: aborting after errors

instead turns into the following (trying to access the field):

$ echo "X" | spicy-driver test.spicy 
[error] test.spicy:9:11: type does not have field 'm'
[error] spicy-driver: aborting after errors

$ cat test.spicy 
module Test;

type ASN1Message = unit(x: bool) {
  tag: uint8;
};

public type X = unit() {
  m: ASN1Messup(True) {
    print self.m;
  }
};

In this case it's still pretty easy to spot. With the LDAP analyzer, it triggered a bunch of more confusing diagnostics.

---

[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:614:30: unsupported operator: <const LDAP::SearchFilter>.<FILTER_SUBSTR>
[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:615:39: unsupported operator: <const LDAP::SearchFilter>.<FILTER_SUBSTR>
[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:684:31: type does not have field 'substring_header'
[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:687:48: type does not have field 'substring_header'
[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:727:35-728:80: not a parseable type (auto)

[bbannier]

This looks like another facet of #1316.