Move error structs from opensearchapi to opensearch to be reused by plugins

[Jakob3xD]

Description

• Move error structs from opensearchapi to opensearch including tests
• Add new errors structs
• Move parseError function from opensearchapi to opensearch error.go as ParseError
• Change ParseError function to do type assertion to determine the correct error type
• Adjust tests to new errors
• Handle non json errors

This is a braking change as the error types are moved to another project and also get renamed.
Needed as preparation for plugin integrations.

Issues Resolved

List any issues this PR will resolve, e.g. Closes [...].

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.70%. Comparing base (06a6dc8) to head (c619002).

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #512       +/-   ##
===========================================
+ Coverage   57.29%   77.70%   +20.41%     
===========================================
  Files         315       13      -302     
  Lines        9823     1673     -8150     
===========================================
- Hits         5628     1300     -4328     
+ Misses       2902      296     -2606     
+ Partials     1293       77     -1216     

Flag	Coverage Δ
integration	?
unit	77.70% <100.00%> (+64.85%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
error.go	100.00% <100.00%> (ø)

... and 304 files with indirect coverage changes

[dblock]

Looks like a publicly-facing backwards-incompatible breaking change? Unless you want to inherit these error types in old names and mark those deprecated, let's bump the version to 4 as part of it?

[Jakob3xD]

Looks like a publicly-facing backwards-incompatible breaking change? Unless you want to inherit these error types in old names and mark those deprecated, let's bump the version to 4 as part of it?

I adjusted the upgrading.md to version 4.0.0. Do you want the release done in this PR or after all my other PRs are merged?
I'd prefer after all the others are merged.

[dblock]

Looks like a publicly-facing backwards-incompatible breaking change? Unless you want to inherit these error types in old names and mark those deprecated, let's bump the version to 4 as part of it?

I adjusted the upgrading.md to version 4.0.0. Do you want the release done in this PR or after all my other PRs are merged? I'd prefer after all the others are merged.

After. Usually the version number should be set on working code as early as possible so that nobody confuses it with released code of the previous version.

[dblock]

Merging this.

Would it make sense to make some of things like ParseError or UnmarshalJSON private only?