libmirprotobuf's ABI can be broken when modifying protobuf message definitions

libmirprotobuf's ABI can be broken when modifying protobuf message definitions.

This is normally not an issue because updates keep replacing libmirclient.so.8 unless we bump client ABI.

Existing clients linked to libmirclient8 (like glmark2) will use the old message layouts, however when linked to newer versions of libmirprotobuf.so.0 at runtime those messages can be bigger or potentially different. Allocating these messages on the stack in libmirclient means this causes stack corruption and crashes.

Ideally, we should bump libmirprotobuf ABI but that's not currently possible since:
- protobuf design does not allow symbols to be registered twice
- libmirprotobuf does not version its symbols
- consequently a libmirprotobuf.so.0 and libmirprotobuf.so.1 cannot be loaded in the same process at the same time
- Loading two libmirprotobuf library versions at the same time would be common since the mesa client platform module is linked against libmirclient - just probing the module would cause a new version of libmirprotobuf to load

The mir team most commonly just adds additional fields to a protobuf message. To improve compatibility in this case, we can avoid allocating protobuf messages on the stack and instead use the factory methods provided by the generated message classes which are defined in libmirprotobuf itself.

We still need to tread carefully when modifying protobuf message definitions however, to avoid changing class layouts in a non-compatible way (like removing fields or adding fields in the midle of existing ones)