Modularize OCPP versions into separate artifacts

[juherr]

Context

Since OCPP 2.0 dropped the WSDL descriptions, the project’s dependency structure differs significantly from previous versions.
Currently, all versions are bundled together, which makes it difficult for users to include only the protocol versions they actually need.

Problem

Users should be able to:

• Select which OCPP versions they want to support (e.g., 1.6 only, or 1.6 + 2.0.1).
• Avoid pulling unnecessary classes or dependencies into their project.
• Build or test specific protocol versions independently.

The current monolithic setup makes it harder to achieve modularity, flexibility, and clean dependency management.

Proposal

Following the approach used in IZIVIA/ocpp-toolkit, we could reorganize the modules as follows:

ocpp-1-2
ocpp-1-5
ocpp-1-6
ocpp-1-6-security
ocpp-2-0-1

Each module would contain its own message definitions, operations, and validation logic.
A shared “core” module could provide the common (datetime serialization, error handling, etc.).

Optionally, an “all-in-one” artifact could be published to include everything for convenience.

Benefits

• Clearer separation of protocol versions
• Lighter dependencies for targeted use cases
• Better alignment with modern modular architectures