Fixed objects being erroneously zeroed out before object construction

[nc-x]

Closes #12753

[mratsim]

It might fix much more than that.

I've always been annoyed by the double zeroMem that required {.noinit.} and it might be the same thing that triggers double zeroMem.

So potentially related:

• Nim compiler performance bottlenecks  #10132
• Performance/genericReset: Make {.noInit.} an unnecessary optimization for heap types #8745
• Assignment in result variables generates genericResets #6501
• Slowness in Nimbus bigints that are used recursively but zeroMem-ed uselessly

See the double memset in the last one:

N_NIMCALL(void, boo2_9aSl0jzccntfjPB4osXEnHA_3)(tyObject_Foo_Bsmztv1sSxNkRrfi5afFAg* Result) {
	tyObject_Foo_Bsmztv1sSxNkRrfi5afFAg a;
	memset((void*)(&a), 0, sizeof(a));
	memset((void*)(&a), 0, sizeof(a));
	newFoo_9aSl0jzccntfjPB4osXEnHA_2((&a));
	genericSeqAssign((&(*Result).s), a.s, (&NTI_qwqHTkRvwhrRyENtudHQ7g_));
	(*Result).val = a.val;
}

[Araq]

There already is a isPartOf check that should be fixed, maybe. Have you looked into it?