Specialise `dyn_ref` to improve value detection

[RReverser]

I think dyn_ref should be specialised where possible to support objects from other realms (for which regular instanceof check would fail).

For example, it's more reliable to use Array::is_array instead of current instanceof Array for .dyn_ref::<js_sys::Array>(), JsValue::is_object for .dyn_ref::<Object>() and probably also existing methods for primitives for conversions to js_sys::Number, js_sys::JsString and so on.

[alexcrichton]

Can you describe what you mean by 'other realms'? Can you also elaborate on some instances that return true for is_object but false for dyn_ref::<Object>?

[fitzgen]

A realm is like a new environment with its own set of globals and all that. https://github.com/tc39/proposal-realms

Related example: if you create a new iframe and get its window's Array, then [] instanceof iframeWindow.Array isn't true.

Can you also elaborate on some instances that return true for is_object but false for dyn_ref::<Object>?

We must be using typeof x === "object" && x !== null for is_object.

[RReverser]

Can you also elaborate on some instances that return true for is_object but false for dyn_ref::<Object>?

I described some of these instances in a relevant, although slightly different issue #1366 - if you create a prototype-less object using Object.create(null), it's not an instance of Object and dyn_ref won't detect it, but it's still a JavaScript object in a wider sense.

But detection will also fail for real Object instances from other realms.

Can you describe what you mean by 'other realms'?

In JavaScript, you can pass values between different "realms", and they each will have own prototype chain which prevents instanceof from working.

This is why some types provide own methods for their detection like Array.isArray, or why people used to do Object.prototype.toString.call(value) === '[object Array]' before that methods was added to the language.

Examples of such realms are iframes on the browser side and vm module in Node.js. Arguably, passing values between them might is more of an edge case, but when you do run into it, it's nice to be covered instead of having to debug weird type errors.

[RReverser]

Btw, while looking into #1087, I realised that this above is needed not only for prototype-less Objects and cross-realm interaction, but also for new primitives which don't have automatic boxing.

Moved into its own issue, since this looks like a bug: #1370