Allow any error to be specified as the Err variant for ResultQuery

[KiChjang]

After paritytech/substrate#11257, we can now return a Result<T, E> for storage map APIs that return a QueryKind. The slight issue here is that the error type must be the pallet error type (i.e. the enum annotated with #[pallet::error]).

There's no good reason for this restriction other than ease of implementation, so I propose that we can in fact lift it and allow any type to be specified as the error variant for the Result returned.

However, maybe what really should happen is to quantify and allow any error that implements the PalletError trait to be specified as the Err variant for ResultQuery, because we may have size limitations on the ResultQuery type. It is in fact unknown to me whether the bounded size of ResultQuery actually matters; maybe we don't care and thus any type can be used as the Err variant.

[bkchr]

It is in fact unknown to me whether the bounded size of ResultQuery actually matters

I don't get why this should be bounded? I mean the error at some point needs to be converted to something DispatchResult compatible anyway. However, this thing doesn't need to be bounded. We don't read the error from the storage.

[KiChjang]

Okay, then we can just allow the Err variant to be of any type.

[shawntabrizi]

Any type that implements Into<DispatchError>... what would be the use case for some other random error?

[KiChjang]

There's no real reason to be restrictive on the kinds of types that we can allow for the Err variant, but it makes sense that we can only allow those that implement Into<DispatchError> to be specified.

Ultimately, the issue here is simply to allow for more error types other than the pallet error enum.

[ggwpez]

There could also be a default error in sp-primitives. Something like StorageItemNotFound.
Then the developer can use that or overwrite with a custom pallet error.