Provide exchangeable interface adapters for the board and shift register libraries

[dhebbeker]

The objective of this pull request is to design interface adapters which provide the functionality necessary for the application's use cases to interact with the input devices and the status indicators of the board.

The design shall be such that the use cases do not depend on

• the implementation of the board
• the implementation of libraries used for this feature
• the selected framework or software development kit

This design facilitates to exchange the board, the libraries or the framework later on. This is desirable because this way we can change those details (things the application's use cases don't care about) without the need to adjust the implementation of the use cases.

[dhebbeker]

I think I found an answer to the question above about whether to put modules into src or lib directory.

The PlatformIO documentation explains:

By default, PlatformIO does not build the main source code from the src_dir folder in pair with a test source code. [...] We recommend splitting the source code into multiple components and placing them into the lib_dir (project’s private libraries and components).

Although this is not the only option available for unit tests, but the recommended one.

I infer that:

• there actually is at least one technical difference whether the modules are put into src or lib directory
• in case unit tests are envisioned for the modules, the recommended way is to put them into the lib directory

[dhebbeker]

• [ ] Explain and justify the include dependency rule.

[dhebbeker]

This diagram has been created with Sourcetrail using the Custom Trail function and the following settings:

• From: ProcessHmiInputs
• All Referenced
• All nodes but 'build-in type', 'enum constant', 'non-indexed'
• Edges: 'type use', 'inheritance', 'member'
• this project file: souretrail-project.zip