Prepare MIW for multi-module support

[OSchlienz]

Motivation

We're introducing sub-modules to the MIW to enable features such as a revocation service, which will be a separately runnable service.

Description

To achieve this the gradle build and settings files must be edited. The revocation service should reside inside a directory called revocation-service. Any changes required to the build system to enable this service should be added tot the sub-module build file. The root level build file can mostly be re-used.

The release GitHub action and accompanying actions should also be prepared for the upcoming feature.

A section in the root-level README.md should be added, describing this architectural change.

The arc42 docs in the docs/ sub-directory should also be updated to reflect the incoming change.

Any other tasks which result from this work, can be added here via a comment.

[nitin-vavdiya]

Hi everyone,

I'm pleased with our progress in converting applications into multi-modules. To further improve adaptability, I suggest decoupling more modules, particularly focusing on key storage and signing mechanisms. This could greatly extend our flexibility for future enhancements.

Considering our current scenarios and what we already know, I propose the creation of a high-level module focused specifically on key storage and signing mechanisms as below:

wallet-api. : Contains constants like DTOs, POJO, Exception, and validation class
wallet-dao: Contains data access layer
wallet-key-storage-api: interfaces to store and get keys
wallet-key-storage-impl-db: Currently we only support databases so we will have only impl for databases. In future may maybe we have wallet-key-storage-vault-impl
wallet-signer-api: interface to sign VC and VP
wallet-signer-impl-local: Sign VC/VP in local. in future, we have wallet-signer-impl-azure
wallet-core: Code services for business logic
waller-service-web: expose rest APIs to sign and verification
revocation-service-client: Contains feign client to access revocation APIs(ie. to get status list and revoke index)
revocation-service-dao: Data access layer
revocation-service-core: Core services business logic
revocation-service-web: APIs for revocation

I understand this is a very big change and requires lots of work.

Please share your thoughts.

Ref:
#285
#254
CC: @PManaras @mustafasalfiti @hkny @borisrizov-zf