[hxb] Reader: lazy type restoring

[kLabz]

Extracted from #11866

[Simn]

One concern might be that the lazies are not resolved before the end of typing. While they should eventually be handled by some follow, this might occur at some point during filtering or even generation and it's not very clear what exactly that means then.

In the real typer we use this make_lazy function which has a force parameter that governs if the lazy is explicitly resolved in a delay. Perhaps it would be prudent to have something similar in the hxb reader, which shouldn't be too hard to add via the api.

[kLabz]

We surely don't want it to be resolved unless really needed during display requests, so that would need to be handled only for full typing (which would bring back some kind of should_lazy_wrap)

[Simn]

Yes I'm talking about non-display requests, that's why I mention filtering and generators.

What I don't like about should_lazy_wrap is that we're putting more logic into the reader. If we keep adding more modes and states then it's going to be quite difficult to reason about anything. So instead of having the reader trying to make informed decisions about whether or not to lazify anything, the API provided to the reader should make these decisions.