Default retry behavior causes rate limited events to be lost and swallows exceptions

This one is hard to explain so I just made a screen recording going over the latest source code:

https://app.usebubbles.com/bpPaAzXS3vWMpZh8tZU3N9/amplitude-retry-behavior-issues

Please let me know your thoughts. We're seeing 429s on our amplitude dashboard and we're looking to catch these 429 so that we can push them to a retry queue for future consumption.

Also, in your readme you say we can create our own retry class with a sendEventsWithRetry method, but then how do we access the underlying transport method?

This would require something like:

```typescript
this._transport = this._options.transportClass ?? setupDefaultTransport(this._options);
```

But your `setupDefaultTransport` function is not exported as part of the npm module as far as we can see

Similarly, to create a retry handler we'll need to implement `RetryClass`, but `RetryClass` is not exported:

```
export class CustomRetryHandler implements RetryClass { // Cannot find name 'RetryClass'
```

Additionally, it seems like the retry logic is currently ignoring the most common kind of throttling. An example of a response payload for a throttled device is:

```json
{
"status":"rate_limit",
"statusCode":429,
"body":{
"error":"Too many requests for some devices and users",
"epsThreshold":15,
"throttledDevices":{
"0ddbe854-d786-4aef-bc9e-b8b7c43e5200":66
},
"throttledUsers":{
"604ac1eb9b1b7a00699d006e":66
},
"exceededDailyQuotaDevices":{},
"exceededDailyQuotaUsers":{},
"throttledEvents":[0,1,2,3,4..]
}
}
```

So in addition to looking at exceededDailyQuotaDevices and exceededDailyQuotaUsers, the props throttledDevices and throttledUsers should be considered. We are now going to write custom logic to handle this case in our own retry class, but it's not ideal. Unfortunately, the "plug and play" promise of Amplitude is far from a reality at the moment