subbusd and subbuspp should add service or subservice name options

[nthallen]

We may soon have a need to run more than one subbusd in the same instrument, so need to be able to distinguish between them. subbusd already has a -s service option to change the service name, but it might make sense to change the subservice instead. i.e. subbus/CAN1 and subbus/CAN2 makes more sense than subbus1/CAN and subbus2/CAN. But, duh, the server owns the service, so we can't have separate servers using the same service. Another approach would be to setup a single subbus server that supports all the necessary flavors for an instrument.

[nthallen]

subbusd_* current does not offer a host-session function interface to specify using a TCP interface. Adding TCP would allow accessing subbuses on remote machines.

The subbuspp library similarly could use a function interface to make it possible to locate multiple subbuses in different locations.

[nthallen]

Note that subbusd.cc defaults to service 'subbusd', not 'subbus', although I setup the DACS module to use the migration library with the 'subbus' service.

[nthallen]

At the moment, we have 3 different subbusd implementations:

• serusb (for DACS, uDACS, Feather, etc.)
• CAN socket (for B3MB, BMM)
• CAN serial (same, but using SLCAN)

In order to support multiple 'flavors' within a single subbusd driver, we would (at least) need to:

• Associate a different device interface to each subservice
• Allow subservice customization to facilitate multiple different serusb devices, for example.

Initialization, if specified on the command line, would need to include:

• subservice:flavor:device

Multiple such definitions could be concatenated with commas.