fix: add name property to exported interface errors

[2color]

Description

As discussed in https://github.com/ipfs/helia-verified-fetch/issues/25#issuecomment-2018003309, this PR adds the name property to the AbortError type.

This has a couple of benefits:

• Sticks the common convention for Error types (all built in Error types have the name property set to the class name)
• Allows checking the error type at runtime in a TS codebase without importing the type

Notes & open questions

• Should we also set the name property on UnexpectedPeerError, InvalidCryptoExchangeError and InvalidCryptoTransmissionError?

Change checklist

• [x] I have performed a self-review of my own code
• [x] I have made corresponding changes to the documentation if necessary (this includes comments as well)
• [ ] I have added tests that prove my fix is effective or that my feature works

[SgtPooki]

https://github.com/nodejs/node/issues/40692#issuecomment-956658594 has some relevant discussions about custom AbortError's too. Also some deets in https://github.com/ipfs/helia-verified-fetch/issues/25#issuecomment-2018375288

[achingbrain]

Should we also set the name property on UnexpectedPeerError, InvalidCryptoExchangeError and InvalidCryptoTransmissionError?

Sorry, missed this - yes, I think we should.

[2color]

Should we also set the name property on UnexpectedPeerError, InvalidCryptoExchangeError and InvalidCryptoTransmissionError?

Sorry, missed this - yes, I think we should.

Ok I'll update the pr

[achingbrain]

Just noticed that DOMException officially doesn't have a .stack property, and technically neither does Error, though every JS runtime adds it - there's a tc39 proposal to add it that's been around for, oh, 8 years 🤦