Add RevisionCode parser and structured board identification

[pjbosco]

Problem

Currently, each BoardModel instance in Pi4J includes a list of revision codes that are directly compared to whatever revision code is read from /proc/cpuinfo. As a result, each time a new revision of an existing board type is released (e.g. a new CM5 variant), a code change must be made in BoardModel to support that new revision. This can lead to some revisions of a specific board type (e.g. a CM5) being auto-detected while others are not, requiring manual intervention to fix.

Proposal

Raspberry Pi has some best practices for board identification using the revision code. This seems like a better approach, as the Raspberry Pi's board type, memory size, and revision - among other things - are all encoded within the new-style revision code. We could parse that revision code and determine the appropriate BoardModel instance in a way that is more resilient to new revisions of existing board types as well as revisions of existing board types that are not well documented anywhere. Using this method, a code change would only be needed when a new board type (e.g. Raspberry Pi 6) is released and the approach would instantly support all variants of that board type (e.g. 2GB, 4GB, 8GB, etc.) with a few exceptions.

I have a working example utilizing this new approach here:
c28a59c

Old-style revision codes are also handled in the new RevisionCode class. BoardModel gets one new method and an update to one existing method. If the new approach fails to find anything, it falls back to the board identification approach that exists today in Pi4J.

Please let me know if you would like a PR for this.

[FDelporte]

Thanks a lot @pjbosco, this seems like a very nice improvement of the BoardModel tool. I just added one comment about merging com.pi4j.boardinfo.definition.Soc with your Processor enum.

Would your implementation in any way "break" on a non-RPi board? Plan is to test Pi4J on more brands soon, so we need to keep that in mind...

[pjbosco]

Would your implementation in any way "break" on a non-RPi board? Plan is to test Pi4J on more brands soon, so we need to keep that in mind...

That's a good question.

This implementation is based on a valid revision code (new-style or old-style) being present in /proc/cpuinfo. For anything else it will result in BoardModel.UNKNOWN unless we make additional code changes. I don't have any of the clones to test so I'm not sure if those revision codes exist in /proc/cpuinfo for those boards. Different clones might have different mechanisms to identify themselves and their hardware. For those boards, it is possible that the /proc/cpuinfo method won't work at all and some new method of detection would need to be used.

I think for those boards, detection would fail earlier in BoardInfoHelper.getBoardVersionCode() because it may not find a Revision line in /proc/cpuinfo in the first place. We might need a completely different strategy to first identify whether we're dealing with a Raspberry Pi board and, if not, try to identify whatever clone we are dealing with based on however that clone identifies itself.

[FDelporte]

OK thanks, please proceed with merge request. We will handle other boards later.