Also generate BYREF AS CONST versions of implicit LET overload/copyctor
Retain vptr in byval object copies (fixes #614)

This adjusts the compiler to
- skip the vptr field when doing a shallow copy
- skip the vptr field in implicitly generated LET overloads

This fixes the main issue of #614: overwriting the vptr during assignments.

Another solution would be to add a copy LET overload to the OBJECT class,
which would simply do nothing, as opposed to copying the vptr. The compiler
would always call this no-op LET overload instead of doing a shallow copy,
and all derived UDT would be given an implicit LET overload, and this way
we could probably also avoid overwriting the vptr.

The problem with that: All the UDTs derived from OBJECT would end up with
a LET overload, and all that just to call the no-op OBJECT.let(). That just
seems stupid...

---

Furthermore, the issue with vptr copying also affects copy-construction by
shallow copy. This patch adds a copy constructor to the built-in OBJECT
type, that prevents any UDTs with a vptr (ie. derived from OBJECT) from
ever being copy-constructed by shallow copy, and initializes the vptr when
copy-constructing an instance of OBJECT.

The problem with copy-construction by shallow copy is that astNewASSIGN()
would have to initialize the vptr (if any) properly, besides doing the
shallow copy of the rest of the object.

It'd be possible to do this, by re-using the hInitVptr() code from
ast-node-proc.bas in astNewASSIGN(), and by making that work with the
OBJECT type too (currently OBJECT's vtable is private in the rtlib's
oop_object.c module, and the compiler doesn't know about it).

But it just seems easier to add the copy-constructor to OBJECT and let it
take care of initializing the OBJECT's vptr. It won't even be used often,
because users typically won't create instances of plain OBJECTs. Usually
OBJECT is just used as base class of other classes, and then their
copy-constructors take care of initializing the vptr.

Also, OBJECT already has a default constructor that initializes the vptr,
instead of having OBJECT given special-handling everywhere in the compiler,
so it makes sense to extend/continue that pattern.