feat: handle database errors

[aaqilniz]

The loopback app generally returns a 500 error code for most database-related errors. This PR adds a generic database error class and returns an appropriate error response by intercepting and modifying it at legacy-datasource-juggler.

Checklist

• DCO (Developer Certificate of Origin) signed in all commits
• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

[achrinza]

I agree it's a good feature to have.

Though I'd push back on two points:

1. Database-specific code should be in each database's NPM package. @loopback/rest can then parse the generalised Error object and map it
   • This would improve future extensibility and ensure that first-party and third-party LB4 connectors have the same features accessible.
   • This allows for non-REST applications to do their own mapping (i.e. don't add REST-specific code in @loopback/repository)
2. Opt-out mechanism
   Arguably this is security through obscurity, but this feature does necessarily expose some of the inner-workings of the application. IIRC 5xx errors are sanitised, but 4xx are not. So perhaps we should build an extensible "mapping" mechanism in @loopback/rest which users can customise?