Fix various issues with object literals

[dcodeIO]

This is a follow-up to #1229 that fixes various issues unrelated to that PR. In particular, classes instantiated from object literals cannot declare a constructor anymore since all kinds of stuff can go wrong with custom logic, with the most prominent one being that we don't know what fields the constructor sets (yet, there's PR for that), in the worst case overwriting those fields with nulls again. The upside is that we can rely on generated constructors for the time being, so field initializers of omitted fields can be applied, fixing the commented out test.

[MaxGraey]

Is it fix this #258 issue?

[dcodeIO]

Unfortunately not. Instead if completely refuses to compile something from an object literal that has a declared constructor.

[dcodeIO]

Appears that to tackle this issue we'll need #1155 so we can reenable support for constructors (see the issue mentioned in the opening comment), and then require constructor parameters to be implicitly declared fields (constructor(public someThing: i32) { ... }) to ensure parameter and field names never conflict.