Add i210 support

[jeppex1]

i210 support is missing and could be useful to add. I'm currently working on an implementation

[xtor]

Excellent, thank you very much for your contribution! It may make sense to implement it in a couple of steps:

1. Add the initial plugin, relying on taprio software mode
2. Add etf qdisc support on top of the above, enabling the use of the launch time feature

Step 1: Add initial plugin

For the first step, the following is required:

1. Complete the i210 plugin
2. Implement the configuration of setup for taprio software
3. Make the Mapping selection pluggable, and check if MappingNaive is more appropriate that the default Mapping, or we need a new one

Probably, configuration will be successful without the last point. But a stream implementation based on software slots would be then artificially limited to the number of queues in the device. This is the case because the Mapping class, as currently implemented, installs a GCL dependent on the number of queues from the device point of view. But taprio in software mode does not suffer from that limit, as it is purely based on software queues. @vcgomes please correct me if I am wrong :)

At this point, we should have a functional plugin able to configure several streams, allocating one Qbv "software slot" per stream :)

Step 2: Add etf qdisc support

This is a little bit more tricky, as more items need to be added and there is architectural impact:

1. Add capability to indicate that the devices support Launch Time Control
2. Make the stream implementation strategy pluggable. E.g. support using just Qbv, with one slot/GCL per stream, or Qbv+LTC, where multiple streams can be allocated within a slot with Qbv.
3. Add interface initialization method exposed via ipc.proto. It would include an optional explicit selection of the stream implementation strategy. If not provided, that with better performance would be selected for each device.
4. Add setup method for taprio software etf, including also the required command strings
5. Extend StreamQosRequest and Response to support e.g. returning a txoffset for the application to use, that accounts for a device-specific correction on the value provided by the CNC

I may be missing something, but that should probably work. At this point, software based Qbv slots would be configured to protect each stream, and the stream itself would be using etf, enabling the application to provide the launch time explicitly via the AF_PACKET socket ancillary data.