Fix warnings: initialize Instruction variables created on the stack

GCC 4.7-4.9 are right that the "code" member is used uninitialized. In
fact, GCC 4.9 was quite assertive about it:

qqmlinstruction_p.h:538:102: error: ‘def.QQmlInstructionData<8>::<anonymous>.QQmlInstruction::instr_common::code’ is used uninitialized in this function [-Werror=uninitialized]
         static void setData(QQmlInstruction &instr, const DataType &v) { memcpy(&instr.FMT, &v, Size); } \
                                                                                                      ^

(It says "is used uninitialized" for this particular case; the "may be
used uninitialized" appears in other places)

The analysis is as follows:
 - variable declared on qqmlcompiler.cpp:1467:
     Instruction::SetDefault def;
 - type is POD, so no initialization is performed (def contains garbage)
 - on qqmlcompiler.cpp:1468 we use the variable:
    output->addInstruction(def);
 - QQmlCompiledData::addInstruction is inlined and does:
        QQmlInstructionMeta<Instr>::setData(genericInstr, data);
 - which is the call above, doing a memcpy with a source (&v) equal to
   the uninitialized "def" variable
 - result: memcpy is copying uninitialized bytes

Valgrind doesn't report this because it doesn't care about copying
uninitialized data. It will only complain if a decision is made based
on it, which we don't since the first thing we do after the memcpy is
initialize the member.

The solution is simple to not copy the common part of the
instructions. This way, we save 8 bytes of unnecessary copying and we
still keep the warning if a member of an extended instruction isn't
set.

Change-Id: I940b40ea9aa61c7386e5cced4a7865be7bfddb5d
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix JavaScript signal connect on alias without other handlers

The changed handlers for aliases are connected lazily in the engine.
QQmlPropertyPrivate::flushSignal is responsible for that and called in other
places, for example when installing a onSomeAliasPropertyChanged handler.
However we were missing a call to flushSignal when doing
onSomeAliasPropertyChanged.connect(...), i.e. using the JavaScript connect API.

Task-number: QTBUG-30493
Change-Id: Ia3f008626fd7af3f2cfbdd30d13fb83158bed4d5
Reviewed-by: Albert Astals Cid <albert.astals@canonical.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix accelerated property lookup on id addressed objects

For properties on id referenced objects, we can ignore the lack of the FINAL
keyword on properties, as we want the same "lexical" lookup rules like for
properties on the scope or context objects. In addition we need to initialize
the resolver on the returned temp, to ensure a successful type determination in
the use of the id object afterwards.

Change-Id: I496c942ade55aa331e6972f06b21c2c86d4b00a4
Reviewed-by: Lars Knoll <lars.knoll@digia.com>