feature: improve the error API

[demurgos]

The current error API is insufficient for advanced use-cases.

The two main limitations are:

• there is no access to structured error information
• there are no public constructors

Some example use-cases where this causes issues:

• integration with error reporters using the core::error::Error::source API
• interoperability with types using other Prost major version (no way to bridge the error types)
• keeping structured information through serialization
• asserting the received error in tests

The previous stringy API was not great either, but it was possible to handle some of these use cases since the constructor was public. Following the changes in #1330, this is no longer possible without hacks.

The following PR is a proposal to fix these issues while avoiding exposing internal implementation details:

• feature: expose public error API for decode errors #1378

[LucioFranco]

Hi @demurgos I think these suggestions are good but at this moment we don't have enough maintenance bandwidth to get this shipped in a way that will be good for the future of prost. So at this moment I can't promise that this will get in anytime soon. Sorry about that.