Safe-Proofing delayedPromise

Nobody has claimed this yet.

If someone `init`'s the keyring twice, or calls `updateTransportMethod` twice quickly while the iframe is loading then you could run into situations where this `if` block runs (see [here](https://github.com/MetaMask/eth-ledger-bridge-keyring/blob/main/index.js#L458)) but when `this.delayedPromise.resolve(result)` or `this.delayedPromise.reject(e)` is called the object is deleted by a separate execution context.

Ways that this could be fixed:
* change `this.delayedPromise` to `this.delayedPromises: Array = []`, and then run something like:
```js
for (const delayedPromise of this.delayedPromises) {
this.updateTransportMethod(delayedPromise.transportType)
.then((res) => delayedPromise.resolve(res))
.catch(e => delayedPromise.reject(e))
}

this.delayedPromises = [];

// and then when the promise is added we do
this.delayedPromises.push({
// ...
})
```
* or, to allow for more flexibility, `this.delayedPromise` could be changed to something like `this.iframeOnloadHooks: Array` and the whole `this.updateTransportMethod` could be contained in the array, in case someone needs to add in a different onload call in later?

Start at the if block in index.js around line 458 and trace how delayedPromise is created, resolved, rejected, and deleted during iframe loading. Reproduce repeated init calls and rapid updateTransportMethod calls, then verify that every delayed operation completes without accessing an object removed by another execution context.

Written by the indexing model from the issue text.