Separate super-deprecated errors from base errors, fix type override, and remove name override

[rattrayalex-stripe]

This is a follow-on to #661

It makes several small changes but the most consequential are:

1. Adding get type() support on StripeError, so subclasses have the property new StripeFooClass({}).type === 'StripeFooClass', which is an important property to uphold. We missed this in Refactor errors to ES6 classes #661 because our StripeError tests had actually been testing GenericError on accident, oops!
2. Remove support for magical .name, which turned out not to be important for backcompat (previously .name was just 'Error') – was a mistake for me to ask for that.
3. Have StripeError inherit directly from Error, and have the default export of Error.js be an "old-school class" to maximize backcompat without any complexity leaking into our proper base class, and to emphasize that it is totally deprecated and will be going completely away. Users should not be relying on the stripe library to extend Error.

r? @richardm-stripe
cc @stripe/api-libraries

[remi-stripe]

Lurk: I don't fully understand the changes, but we should make sure we're trying to be aligned across languages, and when we're not that we know why. We're doing something similar to make accessing errors better in ruby stripe/stripe-ruby#811 and have decided that it's cleaner to do e.error.code instead of e.code. It might be what you're doing I just wanted to flag.
cc @ob-stripe @brandur-stripe

[rattrayalex-stripe]

Ah, thanks! That doesn't actually affect this PR but good to know about. We don't have support for decline_code in stripe-node yet, so we should add that. As for e.error.decline_code vs e.decline_code, IMO we should make that decision on a per-language basis, depending on its idioms (and I'm not sure what the right answer is for Ruby or Node).

[rattrayalex-stripe]

My pretty strong hunch, though, looking at this a bit more, is that we should add these properties directly to the error in stripe-node.

[remi-stripe]

Fair, that's what I meant! Either we document why they are different (more idiomatic or not) or we are consistent but we should make sure to get aligned since today the 4 dynamic libs have no direct access and we're trying to fix that

[richardm-stripe]

All makes sense to me. Can't think of any Javascripty gotchas.