Proposal: is{Type} methods

[jasnell]

Introduces a proposal for adding additional is{Type} methods to intrinsic objects.

For example:

• ArrayBuffer.isArrayBuffer(arg)
• Symbol.isSymbol(arg)
• and so forth...

https://github.com/jasnell/proposal-istypes

[ljharb]

I would love this, but you should be aware that when I previously proposed Error.isError (since it's the only primordial without an internal slot/brand checking method on its prototype), I got a very very large amount of pushback and ended up withdrawing the proposal

https://www.npmjs.com/package/is-date-object is what you get when implementing with the committee's current recommendation (besides "don't brand check").

[doug-wade]

It seems, from my cursory reading, that the argument comes down to "errors aren't really that different from objects and shouldn't be treated as such." I don't think that the same argument could be made about numeric primitives (for example).

[ljharb]

The essence of the pushback was that many on the committee believes that code should not be brand checking, and if an object wants to pretend to be something, it should be allowed to fully perpetrate that disguise (whereas brand-checking would be an unforgeable check).

This can be merged regardless, but I want the champion to be as prepared as possible to present it - for example, Proxy.isProxy will likely never be acceptable, and although I'd love to have all the others, the reasons I've mentioned are why it won't likely even be able to achieve stage 1.

@jasnell given this, if you'd still like this PR merged please go for it!

[rwaldron]

Proxy.isProxy

This stood out as well—a Proxy should appear to be whatever the target object is, eg.