Fix availability and naming of properties and state structs for devices

[heliosfa]

This PR:

• Renames properties and state structures from the incorrect devtyp_{DEVICETYPE}_... format to {GRAPHTYPE}_{DEVICETYPE}_.... (fixes Standard type-name aliases are not emitted #231)
• Move the struct declarations to their own header, DeviceStructs.h, that is used by all devices and the Supervisor. (fixes Types for device properties and state only available within that devices handlers #232)
• Adds #pragma pack(push,1) to the message stuct header. (partially addresses Generated types (e.g. state, messages) don't have packing specified #240)
• Fixes a couple of issues in the apsp_vec_barrier_150_10.xml example that stoped it compiling.

The plate heat example has been updated, and a very simple compilation test added, in POETSII/Orchestrator_examples#14.

Vol III B has had some minor updates: docx|pdf

APSP tweaks:

To get the APSP example to compile, I had to add #include <climits> to the shared code.

I also had to add a const unsigned cast to the second parameter in the calls to std::min to handle:

error: no matching function for call to 'min(const unsigned int&, long unsigned int)'
unsigned curr_k = std::min(K, graphProperties->total_vertices - deviceState->round_base);

There is still a warning that I am ignoring for now:

warning: comparison of integer expressions of different signedness: 'int32_t' {aka 'long int'} and 'unsigned int' [-Wsign-compare]
      if(0 <= id_delta && id_delta < K){

[mvousden]

Looks largely sane to me. More thoughts:

• The fix for #232 is good - splitting those structure declarations off into their own header file will make debugging a fair amount easier.

• Given that application writers are permitted to access these types (as this is a user-facing feature), I think they should be introduced in the application documentation, perhaps with a corresponding example handler 🍠.

• I think the application writer should be told that their message payloads are packed tightly - another documentation update perhaps?

• Your APSP changes also seem sane, though I would suggest addressing the signedness warning (just use a cast in the condition?).

• Since you're fixing #232, can we un-xfail the APSP test? These are denoted in the Bash scripts in Tests/ReferenceXML - they call TODO functions instead of success or failure functions. Do let me know if you need guidance with this. 🍠

• Where I put the 👍, I wondered if requestIdle had been implemented. If so, please "activate" the corresponding tests in the same way as the above. 🍠

[heliosfa]

• Given that application writers are permitted to access these types (as this is a user-facing feature), I think they should be introduced in the application documentation, perhaps with a corresponding example handler 🍠.
• I think the application writer should be told that their message payloads are packed tightly - another documentation update perhaps?

I'll do a docs tweak and PR.

• Your APSP changes also seem sane, though I would suggest addressing the signedness warning (just use a cast in the condition?).

Interestingly, I now cannot reproduce this warning.

• Since you're fixing Types for device properties and state only available within that devices handlers #232, can we un-xfail the APSP test? These are denoted in the Bash scripts in Tests/ReferenceXML - they call TODO functions instead of success or failure functions. Do let me know if you need guidance with this. 🍠
• Where I put the 👍, I wondered if requestIdle had been implemented. If so, please "activate" the corresponding tests in the same way as the above. 🍠

I have enabled both of these tests.

[heliosfa]

Turns out that I had done the docs changes ages ago but forgot to PR them...

[mvousden]

Nothing further to add from prior review, looks good to me.