Simplify logic for looking-up boom error type

[devinivy]

While working on #10 I noticed there there might be an opportunity to simplify some of the logic used to look-up a boom error type from an objection error type.

If I understand correctly this logic is looking for an exact constructor match:

if (error instanceof internals.dbErrorMapping[key][i] && error.constructor.name === internals.dbErrorMapping[key][i].name) {
    return Boom[key](options.includeMessage ? error.message : null);
}

The idea here is to use a Map keyed by objection error classes to do a direct lookup on the error's constructor to see if it is of one of those classes.

[devinivy]

The source of the failing test is actually a recent change to objection. I have a question out to Sami about whether the fix should be to objection or our test suite: Vincit/objection.js@aa1e095#r46314524

[optii]

Looks good to me. If I remember correctly objection didn't expose all the errors directly at the time of creation, they where exposed via objection-db-errors iirc and I think there where some edge cases that couldn't be caught with the Map, hence the loop & check of instanceof & constructor.name. but this is definitely better ! 👍