Misc improvements to internal data structures

[svaarala]

The current data structures for string table, object property tables, etc are for the most part unchanged from the initial 1.0 release. They're functional but are in some need of improvement as they're starting to limit performance and footprint improvements, at least compared to for example bytecode dispatch. This is a high level issue to track the overall changes in the medium term for all changes planned but not yet finished. All changes are prototyped and measured before being actually merged of course.

String handling: #1363

Object property table handling: #1364

Miscellaneous:

• Separate duk_hproxy sub-struct. Add internal duk_hproxy struct #1500
• Separate duk_hboundfunc sub-struct. Add internal duk_hboundfunc type and collapse bound function chains #1503
• Revisit the duk_tval format. It's gone through several iterations between NaN aliasing, explicit union (portability), and tagged pointers. Tagged pointers were rejected for 1.0 release because there was no fastint support which makes IEEE double representation (and without fastints, all integer representation) very awkward. Now with fastint support most common values would be representable as tagged pointers, and Float64Array allows IEEE double heavy arithmetic relatively efficiently and compactly. Tagged pointers have several downsides, but also upsides: for one they can be represented as void * which is convenient to pass around by value. They are also more compact than NaN aliasing.
• To simplify buffer handling, it may be cleaner to separate ArrayBuffer from duk_hbufobj (as it's not a view), and maybe merge plain buffers and ArrayBuffers conceptually, so that a duk_hbufobj could back directly to an ArrayBuffer rather than going through an ArrayBuffer which then is backed by a plain buffer.
• Similar reconsideration for the lightfunc type might make sense. One approach for the C API would be to hide the difference between a function and a lightfunc from C code (same is done for numbers and fastints for example).
• Symbol support currently has no explicit C API type. Consider adding that to simplify C code. It may then need a type tag in the internal representation.
• duk_hobject subtype detection relies on specific flags rather than some kind of enumeration field (class number or similar). Sometimes bit flags are good for fast checking, but when switching over the subtypes a sequence of bit flag tests is not ideal.
• Boxed values (String object, Number object, etc) now use a _Value internal property. Maybe add a duk_hboxed subtype which can hold a duk_tval. This can then be uniformly unboxed for example. Ability to store a "user value" would be useful in general.

Individual backlog issues to consider when touching the internal typing:

• Adding a magic value to the (plain) pointer type Magic also for pointer type #37. This might be possible within duk_tval or might mean making pointers (small) heap allocated structs.
• A way of controlling the prototype of buffer/pointer types Way to set prototype of buffer and/or pointer types #54, Userdata type (pointer with prototype) #844.
• Finalizer support plain buffer/pointer types Finalizer support for plain buffer types #329.
• Ability to support full 64-bit values Guaranteed 64-bit precision for numbers #196.
• More direct support for custom objects (more direct than Proxy that is) Ability to catch array modifications in C #186.
• Eliminate API distinction between plain and boxed strings etc Return string/buffer data for both plain values and boxed values #167, Merge duk_get_buffer() and duk_get_buffer_data() API calls #741. Ecmascript code can also mostly ignore the distinction.
• How to type check object variants (e.g. Uint32Array) efficiently from C code Type checking Uint32Array #752.
• Support for pushing function pointers cleanly Add support for storing function pointer values #808.
• Optimization proposals Check optimization proposals in SmallFootprintJavaScriptEngine.pdf #1061.
• More duk_hobject subclasses Add an internal duk_hproxy type #1136, Add an internal duk_hboundfunc type #1137, Add explicit duk_hdecenv and duk_objenv scope objects #1310.
• Large buffer support Large buffer support? #502.
• Pointer compression handling of NULL; maybe allow NULL to be != 0. Example pool allocator that handles NULL efficiently by leaving a gap in the pointer space. Pointer compression handling of guaranteed non-ROM pointers.