refactor(protocol/reserve): Split Result off error module into its own.

[KirilMihaylov]

No description provided.

[gmanev7]

please provide a sentence about your motivation. There are a lot more examples that are not yet refactored in this way, why have you selected this one exactly?

[KirilMihaylov]

My motivation for doing it, was to follow the example of the standard library of splitting modules when there is logical distinction.
Only worked with this package, so I only changed it here. For consistency, we'd like to do the same for the rest but I think incremental steps would be easier to work with and merge later on.

[gmanev7]

There is a distinction between each two types .... and we tend to group the ones that stay close in purpose and change together.
Here the Result depends on the Error and goes always with it. In the reverse, rarely one uses only Error without Result is not it?
I'll accept this change because I value your efforts but I would be hesitant to propagate such separation just for the sake of consistency with other packages. The motivation is not strong enough to apply it globally.

[KirilMihaylov]

Well, I use the standard library as a "rule of thumb" guide. If it's done that way there, I'd do it the same way as it's the "de-facto" way of doing things.

Otherwise, would you agree to propagate the change of setting it as a default parameter instead? That allows for more flexibility and not having to have StdResult/std::result::Result, CwResult, ContractResult, etc., and instead have a Result for general purposes of the contract and when unavoidable CwResult as an addition?

[gmanev7]

The huge distinction with the standard library is that it defined the trait Error, not a type that implements it.
In our packages we define an Error implementation and a specialization of Result - both are package-specific definitions of error propagation primitives - this was the reason to be defined together.

So no way to make an analogy with the standard library.
If you insist on defining Result and Error in separate modules in this package - OK, but I do not vote for turning it into a rule or practice.