Add additional flexibility to the initialization of DPDK to enable flow isolation

[sbuzzard]

I have a potential use case where I'd like to use isolated flows. The mellanox DPDK driver, which we're using, provides built-in bifracation of DPK and kernel. We'd like to potentially deploy multiple processes against the same port but filtering different inputs. Generally DPDK doesn't support this well, but it is supported with Mellanox by using rte_flow_isolate and then setting the input flow. capsule doesn't provide core abstractions on the flow API but it does provide FFI so that a user can still use these. That said, the rte_flow_isolate needs to be called after eal initialization but before dev config, which in capsule is incorporated, directly or indirectly via port builder, in the Runtime::from_config function. We can't really write an alternate from_config due to the functions needed for it are often private to capsule crate. And I wouldn't really want to since the details of this function are crucial to setting up capsule in general and part of why we use it rather than rolling our own. We aren't sure we want to separate out inputs into separate processes but would like the possibility. capsule could perhaps provide an alternate function (or parameter to the function) to execute rte_flow_isolate (with enable = 1) and have the config set to indicate flow_isolate is set so that on shutdown, you can call rte_flow_isolate (with enable = 0 - not sure you need to do the latter but it's probably good form). I think the flow_isolate would have to be in port builder since I think the port I may try this in a fork but at least wanted to document this desire.

[sbuzzard]

Not that I've recommend this necessarily, but this is what I'm doing as a work-around to make flow isolation work .