Duplicate property names

Nobody has claimed this yet.

Something I've just noticed while trying to add types for this on DefinitelyTyped (not really necessary by any means but I'm kind of a stickler for that kind of stuff).

You've exported duplicate property names with varying values more than once in several places. For example `STRING_DATA_RIGHT_TRUNCATION` is defined both here:

https://github.com/LinusU/pg-error-constants/blob/5cb96f191df6346c51e2c5c9e7c9d8a9060ffd93/index.js#L11

As well as here:

https://github.com/LinusU/pg-error-constants/blob/5cb96f191df6346c51e2c5c9e7c9d8a9060ffd93/index.js#L93

As we can see, the former value ('01004') differs from the latter ('22001'). Obviously this will end up just overwriting the former *with* the latter, so that the former is not available to consumers of the package.

I'm assuming this package was created by simply copying the table directly from the [postgres docs](https://www.postgresql.org/docs/current/errcodes-appendix.html), which features the same table and the same duplicate condition names.

The duplicate condition names in postgres docs seem to indicate that quite often multiple different codes map to a single condition code. If that's the case, then the approach of checking `error.code` against a single string constant with `===` cannot be reliable:

```
const { STRING_DATA_RIGHT_TRUNCATION } = require('pg-error-constants')

if (err.code === STRING_DATA_RIGHT_TRUNCATION) {
// This will fail to identify the '01004' code.
}
```

I suppose you could export these as arrays of strings and alter consuming code to check for array membership. Or possibly provide some kind of utility function for doing the check. Either way it would probably require some major breaking changes, and to some extent it might not even make sense to suffix such a module with `-constants`.

I've found these constants pretty helpful so far, so I'd be happy to contribute such changes if you're open to them.

Start by inspecting the duplicate definitions in index.js and compare them with the PostgreSQL error-code appendix linked in the issue. Determine whether the intended change is to preserve all codes for a condition or to provide a different matching API, then define the required consumer-facing behavior and corresponding coverage before implementation.

Written by the indexing model from the issue text.