ISO 15118-20 messages are not consistent with ISO 15118-2 and DIN 70121

### Describe the problem

I will prefix with saying I am not an XML schema expert, so this could be barking up the wrong tree...

ISO15118-2 keeps messages structured as:
```
message
header
body
specific message
```
So can easily decode the message, check the header, then pass the body for message specific handling.

Current ISO15118-20 cbv2g keeps messages structured as:
```
message
specific message
header
specific message
header
specific message
(no header for some types)
```

But the schema defines a hierarchy of:
```
V2GMessageType
Header (Header)
V2GRequestType
specific message

or

V2GMessageType
Header (Header)
V2GResponseType
ResponseCode
specific message

```
Flattening out this heirachy has made it much harder to handle messages in an abstract manner (e.g, just the header or the response body). An example is:

```
struct iso20_SessionSetupResType {
// Header, MessageHeaderType
struct iso20_MessageHeaderType Header;
// ResponseCode, responseCodeType (base: string)
iso20_responseCodeType ResponseCode;
// EVSEID, identifierType (base: string)
struct {
char characters[iso20_EVSEID_CHARACTER_SIZE];
uint16_t charactersLen;
} EVSEID;
};
```

IMO, keeping the hierarchy like in ISO15118-2 messages would be much more useable and also consistent.

Also, Initializing each specific req/res message type does not initialize the Header field which is a member of that type. Actually helpful in practice, but inconsistent and how can a user be sure it wont change in the future.

Having Header in the message means you also cannot memset/zero the message as wipe the header. memset is needed as the init functions don't init every member to a known/safe value. The header is meant to be unrelated to a specific message so should be able to work on a specific message without altering the header I think. Technically the same should apply to Response Code. Should be able to set that for any response message, then fill out the specific message details without fear of overwriting it.

Of course all this can be worked around, but when converting -2 code to start handling -20, I saw how much more difficult these structures were to manage than the -2 ones.

Probably too late to change now but... Thoughts?

### Describe your solution

Make the message structure hierarchical, something like:

```
struct V2GMessageType {
MessageHeaderType Header;
union {
V2GRequestType Request;
V2GResponseType Response;
}
unsigned Request_isUsed : 1;
unsigned Response_isUsed : 1;
};

struct V2GResponseType{
ResponseCode Response;
union {
SpecificResTypeA;
SpecificResTypeB;
};
SpecificResTypeA_IsUsed : 1;
SpecificResTypeB_IsUsed : 1;
};

struct V2GRequestType{
union {
SpecificReqTypeA;
SpecificReqTypeB;
};
SpecificReqTypeA_IsUsed : 1;
SpecificReqTypeB_IsUsed : 1;
};

```

### Additional context

_No response_

The issue names no repository files or tests; start by locating the ISO 15118-20 cbv2g schema and the generator entry point that emits types such as iso20_SessionSetupResType. Compare its output with the ISO15118-2 hierarchy, then verify that generated request and response structures consistently place Header and ResponseCode outside specific message data.

Written by the indexing model from the issue text.