v4: Manually inline the access to the execution engine

Executing an allocation heavy testcase of JavaScriptCore on my
i7 Sandy Bridge notebook 6.85% is spent inside the ::engine()
call as gcc 4.8.2 of Debian didn't inline the call. Inline the
call sites by hand. I removed the protected ::engine() as it is
now unused.

$ time qmljs JavaScriptCore/tests/perf/bench-allocate-nonretained.js
before (best run of three)
real	0m2.234s
user	0m2.228s
sys	0m0.008s

after (worse run of three)
real	0m2.097s
user	0m2.088s
sys	0m0.008s

Change-Id: I20b73b3b3dac630eb1d5e7d66bcb50c839630567
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
v4: Remove dead code ScriptFunction constructor

Creating a Scope/ScopedValue will immediately access ExecutionEngine
of the ExecutionContext so the null check is not needed here. Move
the v4 variable into the scope that is using it.

Change-Id: I9189ee9d1a63997119e49c12182dffefadc916f1
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
v4: Delay creating the ScopedValue/ScopedProperty in objectLiteral

Creating a ScopedValue/ScopedProperty is not free. It will use the
ExecutionEngine directly to reserve memory from the JS Stack. In
tests/manual/v4/v8-bench.js and bench-allocate-nonretained.js a lot
of objects are created and the arrayValueCount and the
arrayGetterSetterCount are 0. We can delay the creation for a small
gain.

When generating the code we already know the various sizes and
could already call specialized versions of the creation code. The
gain is not so clear though.

Change-Id: Ic99b241f5506457e57611ad4eba143c56be1f657
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>