Padding fields

[treiher]

A built-in syntax for defining padding fields could simplify message specifications. Due to the semantics of reserved/padding fields (cf. #601), opaque fields are not the optimal solution. In the SPDM specification, the need for reserved fields of various sizes led to a long list of reserved types:

   type Reserved_1 is range 0 .. 0 with Size => 1;
   type Reserved_2 is range 0 .. 0 with Size => 2;
   type Reserved_3 is range 0 .. 0 with Size => 3;
   type Reserved_4 is range 0 .. 0 with Size => 4;
   type Reserved_5 is range 0 .. 0 with Size => 5;
   type Reserved_6 is range 0 .. 0 with Size => 6;
   type Reserved_7 is range 0 .. 0 with Size => 7;
   type Reserved_8 is range 0 .. 0 with Size => 8;
   type Reserved_15 is range 0 .. 0 with Size => 15;
   type Reserved_16 is range 0 .. 0 with Size => 16;
   type Reserved_24 is range 0 .. 0 with Size => 24;
   type Reserved_32 is range 0 .. 0 with Size => 32;