Handling of flow table limits could be infallible

We addressed unwraps when OPTE hits limits adding new flows to the UFT in #347. However, during the discussion, starting here, we agreed that the approach the PR takes will solve the immediate problem but has some drawbacks. This issue tracks implementing other options, which should simplify the surrounding code.

In general, we'd like to make adding UFT entries infallible. That could be done by either having new entries displace the oldest ones. The UFT type needs to change significantly to do that, since we have no way of getting the "oldest" entry (or any entry by time) now. Another option would be to completely clear the UFT in this case. And a third would be to not add a UFT entry at all, but fallback to layer-processing all the new flows (until space is available perhaps).

The first option seems the best, but it does mean there's some thrashing and also requires the most code. The other options are simpler, but do mean that new flows (which probably are going to be used more than older ones) are slower. This issue does not cover perf or benchmarking, but having basic workloads that cover some of these cases would be very helpful here.

Start with the UFT type and the flow-addition handling discussed in issue #347, including the linked comment. Compare the proposed eviction, clearing, and layer-processing fallback options; done means selecting and implementing an infallible UFT-entry policy, with basic workloads covering the relevant limit cases.