[FEATURE] Add Op-Code parameter data

[RichardCrawshaw]

Add two new data blocks to the cbusdefs.csv file.
CbusOpCodeParams describes Op-Code parameters for each Op-Code. Data has been sourced from Developer’s Guide for CBUS (Version 6c Draft 5). CbusOpCodeParamDef describes the definition of each Op-Code parameter; including its data-type and a description. Currently only byte, unsigned 16 and 32 bit intergers, char and string are included.

[pnbgit]

I'll check this through for you Richard, and make sure it builds ok in the various language formats that I use. No reason it shouldn't, of course. Give me a few days to do that, my mind is on other things this week.

[spikyian]

I agree that the parameter data should be added. The format and parameter names are slightly different to that which I used in CbusIO but the cbusdefs compiler should be able to generate something close that could be used:
Opc.txt

[spikyian]

So your PR only changes the cbusdefs.csv file. The generation bash script will also need to be changed for users to be access the parameters and that is where the difficutly arises as to the format of the files to be created.

[RichardCrawshaw]

Yes, the current change is only to cbusdefs.csv. This was deliberate. I see the overall inclusion being a two step process: (1) agree the format and add the new data; (2) update the generation scripts. I think that there's little point in making the changes to the generation scripts if there isn't agreement on the data structure. I'm happy to update the C# code once this PR is approved; I'll also be looking to update it to .NET8.0, and possibly add an Incremental Source Generator. (Incremental Source Generators are the current mechanism for handling this type of process in the .NET world.)
I think it would better if someone(s) familiar with bash script were to handle the other generation scripts: I remember there were issues in the past where the Windows scripting host behaved differently to the Mac / Linus one.

[pnbgit]

Richard, would you be happy to bring the [AddOpCodeParams] branch to this repository? Then all work for this can be done in that branch and keep master clear of it until it is all finally agreed and tested.

[RichardCrawshaw]

In principle yes. However, I don't have write access to the cbusdefs repository. So I can't make that change. It may be possible for a contributor of cbusdefs to create a suitable branch and to change the target of this PR. But I don't appear to be able to do that.

Provided that everyone is happy with the data structure in the new data blocks then pushing that change to master should be fine. It will make no difference to existing consumers of the data: they should continue to have the same functionality as before, they just won't yet get the benefit. But it's your repo, so your call.

[pnbgit]

I'll sort out your write access so you can make that change

[RichardCrawshaw]

After looking at using the generated results of the request / response data block, I've realised that some way of linking a response back to the request is needed, such as matching the Node Number or Session. But this information isn't part of the data. It is also only necessary to link one way between a request / response or request / error. So I'm proposing a different pair of data blocks: CbusOpCodeReplyTo and CbusOpCodeErrorReplyTo, that link a request OpCode to a response and an error OpCode respectively.
I'll work through the generation process and update this PR in the next few days.