V7: Improve type definitions

[bengourley]

The PR improves the types in various ways

• does away with the hacky way config was extended for each platform
• makes request, app and device more specific, and reuses their definitions
• adds more rigourous tests, which are written in typescript – ensuring the types actually match the JS object at runtime

[bugsnagbot]

@bugsnag/browser bundle size diff

	Minified	Minfied + Gzipped
Before	40.63 kB	12.29 kB
After	40.63 kB	12.29 kB
±	No change	No change

Generated by 🚫 dangerJS against 7d7b3cb

[djskinner]

What's the rationale for introducing nesting types under AbstractTypes / common?

As a TS user if I want to look at the type signatures of the SDK I think I'd rather see the more concise:

export function notify(error: NotifiableError, onError?: OnErrorCallback): void

compared with:

export function notify(error: common.NotifiableError, onError?: common.OnErrorCallback): void
or
export function notify(error: AbstractTypes.NotifiableError, onError?: AbstractTypes.OnErrorCallback): void

I'm not sure AbstractTypes or common adds much to the signature.

[bengourley]

I was on the fence about the nesting anyway – I saw it as a good way to structure the miscellanaeous types that were not typically needed by the user but were exported just case. But I have just flattened and exported them all at the top level, which removes the nesting and the dubious name.