Allow returning of CallErrors

[VolkerLieber]

Based on #219 , this implements the Error interface for CallError and the corresponding type check for sending the error data.

This is done rather simple, so please feel free to suggest improvements.

[lorenzodonini]

Hey and thanks for adding this. It makes a lot of sense to be able to send arbitrary OCPP errors in responses. Your approach is simple and effective so I'd keep it that way.

However I believe you are misusing the ocppj.CallError type in this case. CallError is the actual struct that will be serialized to JSON in the response. OCPP1.6/2.0.1 are technically unaware of this type and imho shouldn't directly use it that way.

A cleaner way would be to use the ocpp.Error type, which conforms to the error interface and also provides a constructor method. The constructor sadly expects a MessageID param as well, but for this use-case it can be safely ignored (empty string will do), since the logic you added unwraps the struct to then pass only the code and description to the SendError invocation. WDYT?

[VolkerLieber]

Thanks for the input. You are correct, ocpp.Error seems to be a better solution.
I've added a NewHandlerError function to be more user friendly.
It looks like you had something like this already in mind and used NewError in your own handlers.
If possible, please look into the changes in ocppj.go -> ParseMessage as well.

[lorenzodonini]

A test is now failing at ocppj_test.go:647. To verify the new behavior the assertion should be:

assert.Equal(t, protoErr.MessageId, messageId) // unique id is returned even after invalid type cast error

[VolkerLieber]

Sorry for the long delay, should be fine now