`Port<N>` should require `Send + Sync` bounds

[FelixMcFelix]

This is currently the last clippy warning that routinely haunts XDE:

kyle@farme:~/gits/opte/xde$ cargo clippy
    Checking opte-api v0.1.0 (/develop/gits/opte/crates/opte-api)
    Checking opte v0.1.0 (/develop/gits/opte/lib/opte)
    Checking oxide-vpc v0.1.0 (/develop/gits/opte/lib/oxide-vpc)
    Checking xde v0.1.0 (/develop/gits/opte/xde)
warning: usage of an `Arc` that is not `Send` and `Sync`
    --> xde/src/xde.rs:2379:8
     |
2379 |     Ok(Arc::new(pb.create(net, limit, limit)?))
     |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: `Arc<Port<VpcNetwork>>` is not `Send` and `Sync` as `Port<VpcNetwork>` is neither `Send` nor `Sync`
     = help: if the `Arc` will not used be across threads replace it with an `Rc`
     = help: otherwise make `Port<VpcNetwork>` `Send` and `Sync` or consider a wrapper type such as `Mutex`
     = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#arc_with_non_send_sync
     = note: `#[warn(clippy::arc_with_non_send_sync)]` on by default

warning: `xde` (lib) generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 8.88s

I looked into tackling this as part of #744, but we have a large enough number of internal traits that this would add a lot of noise to the scope of that PR. It shouldn't be hard, it's just a lot of busy work and + Send + Sync bounds to chase down and sprinkle around.

Note that the clippy lint itself does not help us identify which structs or traits are causing us to fail that bound. We probably need some form of sentinel machinery (compile-time-only fn or trait applied to Port which enforces the Send + Sync bound?).