Add gRPC API to applaunchd

Close for NN 14.0.2

Yes, I am of the opinion that they should be decoupled, as we don't want to tie potential users of agl-compositor to applaunchd if we can avoid it.  Having an example shell client API that can potentially be reused or reimplemented by whatever a member builds on top of agl-compositor seems better to me since it'll be more flexible.  One thing I'll note is that you may want to not copy the gRPC server implementation I've used in applaunchd as is, as the async or newer function callback APIs in gRPC may be better suited than the simpler sync option I went with for applaunchd.

I've been skimming through these changes, and revisiting the comments in https://lf-automotivelinux.atlassian.net/browse/SPEC-4528#icft=SPEC-4528, and our discussions are leaning towards having the changes that add support for various surface roles to be inside the client shell rather than going into applaunchd.

I just want to make sure this is the design we're after. If, for instance, a client would to like to start an application will use a gRPC interface to applaunchd, and if it wants as well to activate other application will have to use a gRPC that we might have in the shell client? Is that a correct assumption @Scott Murray?

If so, it seems to me that these are really decoupled and I can start writing some mock-ups with gRPC in homescreen, as the protobuf would will different than the applaunchd uses. I'm not familiar with protobuf design and implementation so I'll probably ask for some help and reviewing things.