Don't rely on classes for error handling

[vgrichina]

Currently structured errors are represented by custom TypeScript classes for every error type. This has few drawbacks:

• checking if smth is instance of type is unreliable in JS. It breaks down easily once there are multiple versions of library in given environment, similar to problems with serialization (see Switch to use strings for serialization naming #330)
• a lot of boilerplate (including some code gen) is necessary to support this
• every time nearcore introduces new error types – there is a need to do codegen, make new near-api-js release, etc

Given dynamic nature of JS we would be better of just doing generic TypedError with following fields:

• type – error type string. Used to check which type of error it is.
• data – whatever detailed data JSON object attached to error. Used as parameters when formatting errors for UI, etc