Separate protobuf messages from buttplug to consumer into system messages and return values for client/device "method" calls

[kitlith]

Feature Description

See title, the idea is that since every call now takes a callback, we can more strongly type the protobuf messages that consumers receive back from FFI proper.

[kitlith]

hmm, i think there's going to be a bit more involved here, actually.

First off, ClientMessage, DeviceMessage, and ButtplugFFIServerMessage have unused fields, in the form of id (and index for device), and otherwise wrap *.FFIMessage. We should be able to ditch those unused fields, and then bring the contents of FFIMessage into the outer message, meaning that an inner FFIMessage is no longer necessary.

Second off, I think the Ok and Error messages can be lifted up to the top level, and we can start creating 'Result' messages. i.e.

message ResultVoid {
  oneof msg {
    Ok ok = 1;
    Error error = 2;
  }
}

message ResultDeviceEvent {
  oneof msg {
    DeviceEvent ok = 1;
    Error error = 2;
  }
}

maybe with types for the individual sub-messages of DeviceEvent instead of DeviceEvent itself, to make some things potentially even easier.

also, TIL about protobuf's service definition, which is separated from gRPC -- aka we can build our own """RPC""" system that can work with protobuf that serves our need of crossing the FFI boundary. This may be worth further investigation.

[kitlith]

mark this as something to consider for ffi core 3.0 i guess, if we don't decide to nix protobuf entirely by then.