std/json: remove macro type API usage

[saem]

Summary

Remove usage of macros type API usage in std/json, specifically
getTypeImpl and getTypeInst. This is part of a broader effort to
drop this API from the standard library. The current API enforces a
number of poor design decisions in compiler internals. The API itself
is questionable and much of this work should happen via generics.

Details

As part of removing the usage of these APIs, there was a slight
regression in the precision of errors when a tuple without named fields
is used. The error message is equivalent, but the error location will
be within the json module itself.

The change itself uses the fieldPairs iterator which relies upon
compiler support in semfields. Some minor adjustments were made here
in particular the ability to handle nkError nodes.

The json module relies upon the ability to forward declare generic
procedures, this was not possible with the earlier bootstrap compilers,
and existed behind a conditional compilation flag
(nimFixedForwardGeneric). Seeing as this is no longer the case the
flag has been removed as part of the module rework.

Finally, the test tjsonmacro_reject existed for the previous approach,
but the test are combined into tjsonmacro and the previous test is
removed.

[saem]

Next thing to fix is handling the error pragma handling, presently only in the VM, it probably needs to be in sempass2, as well.

error in macros is implemented a bit oddly, it can only execute in the VM and it's far too general a name. the whole api is infuriating, what should be a simple static call that can be folded is instead tangled up in macro land.

[zerbina]

Looks good to me! It's a lot less code now, and the version using generics is much easier to understand too. I've left a few clean-up suggestions.

As an aside, the removal of nimFixedForwardGeneric makes the final change-set a bit hard to read. Turning the removal into a separate PR would be nice, but it's not something blocking -- no change expected from my side here.

[zerbina]

Suggested change

	assert obj.kind == tyObject, $obj.kind
	assert obj.kind == tyObject

[saem]

wouldn't it be easier to debug by leaving the kind in there?

[zerbina]

It would, although I personally think that assertions with $x are visually a bit noisy, hence my suggestion. It's nothing critical, however, and I'm fine with it staying as it is.

It's nothing for this PR, but since asserting that the discriminator of some object has a certain value is a common pattern in the compiler, I think that adding a new idiom assertKind (which automatically renders the value on failure) would make sense.

[zerbina]

I've applied some small typo and grammar fixes to the PR message.

[saem]

/merge

[github-actions]

Merge requested by: @saem

Contents after the first section break of the PR description has been removed and preserved below:

---

Notes for Reviewers

• part of a bigger sweep through the stdlib to remove all such API usage