API doc note: prop access base can be any value
Merge branch 'doc-propapi-value-note'
Ditz issue update
FIXME downgrades for omitted API docs
Merge branch 'api-doc-fixme-cleanup'
Ditz issue update
Fix assert bug (caused incorrect assert failure)
Merge branch 'fix-nullptr-in-assert'

Fix pointer bug in assert which caused an incorrect assert failure.
Testcase for bound initial function of a thread

Currently, this testcase fails.
Merge branch 'bound-function-thread-start'

Testcase demonstrating a current limitation: initial function of a new
coroutine cannot be a bound function.
Ditz issue update
Implement duk_set_global_object() to API
API testcase for duk_set_global_object()
API doc for duk_set_global_object()
Release note: duk_set_global_object()
Merge branch 'api-set-global-object'

Add `duk_set_global_object()` API call which allows user code to replace the
entire global object.  This allows limited sandboxed environments with no
access to e.g. `eval()` or `Duktape` from Ecmascript code.  Because a new
object can be built from scratch, there are no limitations on how to set up
the property attributes in the sandbox.

This mechanism has limited effect on the C API: you can eval strings even if
the new global object has no `eval()` binding.  This is the case because the
eval API call accesses the internal built-in object indirectly.

Similar issues affect Ecmascript code too.  For instance, you can create
RegExp instances using regexp literals and thus gain access to the original
RegExp prototype, even if there is no RegExp class in the new global object.

As such, this is not nearly a complete solution for sandboxing, but an
important piece of it.