`discv5.getKadValue` returns incomprehensible error when looking up own ENR

After having seen this sort of issue on and off when in various edge case scenarios in Ultralight where a node mistakenly queries its own routing table for its `nodeId`, I've finally figured out the source of this error and want to ask if there's a "best practice" solution for it. The issue is:

```ts
discv5.getKadValue(discv5.enr.nodeId)
```

produces this very hard to understand error
```sh
TypeError: Cannot read properties of undefined (reading 'getValue')
at KademliaRoutingTable.getValue (file:///home/jim/development/discv5/packages/discv5/src/kademlia/kademlia.ts:156:23)
at Discv5.getKadValue (file:///home/jim/development/discv5/packages/discv5/src/service/service.ts:214:30)
at Context. (file:///home/jim/development/discv5/packages/discv5/test/e2e/connect.test.ts:69:21)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
```

The reason this error is produced is because when you compute the `log2Distance` for your own nodeId, the distance is 0 and so [`RoutingTable.bucketForId`](https://github.com/ChainSafe/discv5/blob/1cdc424bca9efa8c260276514460f42b2e2593dd/packages/discv5/src/kademlia/kademlia.ts#L240) computes a bucketId of -1 and there is no bucket at that index.

It would be nice if we could either return `undefined` (since the ENR isn't in the routing table) or else throw an error that makes more sense like "Don't look for your own ENR in your routing table" (which might be cleaner since it really doesn't make sense to look for your own ENR in your own routing table).

Let me know if there's a preference and I'll raise a PR accordingly.