Array handling improvements, fix GH-2023

When array size is limited to 16 bits, some internal operations which
don't support abandoning the array could try to grow it beyond 16 bits
rather than abandoning the array part.  This caused an assertion failure
and also potentially memory unsafe behavior.

Changes:

* When growing the property table, sanity check entry and array sizes.
  If the new values won't fit in the duk_hobject structure (which may
  happen with 16-bit fields), fail the grow attempt with an internal
  error.  This avoids field truncation and potentially memory unsafe
  behavior as a result.

* Rework array part growth vs. abandon code to avoid the GH-2023 issue.

* Add support for keeping array part when possible into
  Object.defineProperty().

* Add support for abandoning array part when using internal variants
  for defining properties (such as in Array .map()).

* Executor compile warning fix.

* Debug logging trivia, downgrade a noisy log entry.

* Fix compile warning in duk_cmdline.c.

examples/cmdline/duk_cmdline.c

@@ -229,7 +229,7 @@ static duk_ret_t wrapped_compile_execute(duk_context *ctx, void *udata) {
  memcpy(buf, (const void *) src_data, src_len);
  duk_load_function(ctx);
  } else {
- duk_type_error(ctx, "bytecode input rejected (use -b to allow bytecode inputs)");
+ (void) duk_type_error(ctx, "bytecode input rejected (use -b to allow bytecode inputs)");
  }
  } else {
  /* Source code. */