Misc object property handling improvements

[svaarala]

• Rethink the object property table data structure. It would be nice to eliminate the variants to simplify code maintenance. Related pending pull: Remove unused duk_hobject property layout(s) #815.
• Current layout ensures keys are in sequence for fastest linear scans. With more eager hash tables, slot caching, or own/full property caching this is less important and data locality for key, value, and attributes would be nice for cached accesses. Ideally one property read would be a cache lookup and one cache line read for the value. The layout might be different for objects with and without a hash. A different layout for packed low memory targets vs. default desktop targets might make sense.
• Guaranteed property slots for e.g. internal values might simplify certain accesses.
• Use a better hash for the object property table. Current hash is similar to the string table and is based on a MOD operation; load factor issues are similar. However, hash tables are only used for relatively large objects. Rework object hash part algorithm #1284
• For object hash: keep probe step as 1?
• For object hash: 16-bit hash part (works well with slot cache)?
• For object hash: drop hash parts on emergency GC?
• Make the hash part react to property read/write activity, so that objects with a lot of traffic more eagerly get a hash table and vice versa. This can be achieve via counts, or by random sampling (= if sample check is true, add hash table for property being queried).
• Other inputs to deciding when to add a hash part, for example: (1) a frozen/sealed object is likely to be long term and worth a hash, (2) an object used as an internal prototype of another object is likely to be accessed a lot. Based on Rework object hash part algorithm #1284 the hash lookup more or less always pays off (at least if property count is >= 4), as long as the overhead of creating a hash table can be paid off.
• Improve property lookup handling. Current approach is monolithic which makes maintenance harder than necessary. Also performance would improve if exotic behaviors would be confined to a separate slow path (either separate functions for every class of objects, or a fast path and a slow path for common vs. rare objects). A useful minimal step might be to separate plain object/array handling from the generic case. Also handling primitive base values could be confined to a slow path.
• Property lookup caching is one common improvement (with downsides too). Positive caching (= hit) matters most, negative caching much less in most practical code (negative caching does help e.g. in JSON.stringify() when mostly missing .toJSON() call is looked up for every object). Property value/storage cache prototype Implement an initial version of property caching #1214. Property slot cache prototype Add a best effort heap-wide object property slot cache #1289.
• Speeding up inherited property accesses are possible using e.g. a very simply Bloom-filter-like hash mask which allows a quick reject ("property is certain not to exist for this object").
• Internal idiom for creating an object with a set of preallocated property slots which can be written in directly without any resizes or property operations.