v201:call,call_result,datatypes: complete and corrected type annotations

[malsyned]

I groveled through the v2.0.1 spec and updated all of the type signatures to be complete and accurate to the best of my ability.

I did this to support some work I'm doing to make a variant of @on that converts the JSON back to Python objects, but I think it will be useful to anyone using the library with an IDE, so I'm submitting it as a separate pull request.

[malsyned]

I think this change is a superset of #529 and contains all of those fixes.

[jerome-benoit]

The PR contains at least a serious fix to total_cost type, which is a showstopper at implementing an OCPP2 server compliant with pricing regulation with that library. The rest of PR is also refining properly a bunch of types definition.

[malsyned]

I rebased this so it will merge cleanly with master, and added the suggested additional type fix from @jerome-benoit. This should be good to go now.

[jerome-benoit]

@OrangeTux, @Jared-Newell-Mobility, @jainmohit2001: is there a chance that trivial PRs such as that one making the developer experience way more comfortable while enforcing strong types get reviewed and merged?

[jainmohit2001]

HI @malsyned, can you help with the following question?
Let's say the charger sends an Authorize request to the central system, we have the following handler in place:

@on(Action.Authorize)
async def on_authorize(self, id_token: dict, *args, **kwargs):
    status = AuthorizationStatusType.accepted
    return call_result.Authorize(id_token_info={"status": status})

Currently we have the following signature for Authorize dataclass:

@dataclass
class Authorize:
    id_token_info: Dict
    certificate_status: Optional[str] = None
    custom_data: Optional[Dict[str, Any]] = None

What would happen when we change the signature of Authorize to the following:

@dataclass
class Authorize:
    id_token: datatypes.IdTokenType
    certificate: Optional[str] = None
    iso15118_certificate_hash_data: Optional[List[datatypes.OCSPRequestDataType]] = None
    custom_data: Optional[Dict[str, Any]] = None

Do I need to make any changes to my @on handler?
How should I benefit from the new signature for Authorize dataclass?

[malsyned]

@jainmohit2001 I don't think you would have to make any changes, but I haven't looked at this in a while. I was working on an experimental @on-style decorator that uses these more specific type signatures to create ocpp objects, but as the library works now, the handler just receives a dictionary, and that shouldn't change because of this PR.