synchronous Forwarding/PortManager APIs

Reviewer: @kenchiang

The Indigo2 architecture was designed to support both synchronous and asynchronous processing of calls into the Forwarding and PortManager modules. In practice all currently maintained implementations are synchronous. The async support was complex, buggy, and inefficient, causing problems even if it was unused. Removing it improves the quality of current switch implementations and opens the door to implementing a different, more useful way to defer barrier replies.

The changes are similar for each API. The error code and any other result are moved from the callback to the Forwarding (for example) interface and the callback is removed. The OFStateManager code for the message handler and the callback are smashed together and redundant code (like temporary memory allocations) is removed. Finally the unit test is updated to use the new function signature.

A few places see more significant changes. Since flows can no longer be in any state other than "created" (aka stable), the flow entry state is removed. Similarly, there can never be ongoing operations blocking a modify/delete of a flow, so the queued_reqs infrastructure is removed. The flow stats code is greatly simplified because we don't need to multiplex the logic for expiration, flow stats, and aggregate stats in the flow stats callback. Deleting the entire flowtable no longer requires duplicating the deletion flow-mod for each entry.

I've tested this using OFTest with LRI. I'll open pull requests to update LRI and IVS once this goes in. The modifications needed to the Forwarding/PortManager implementations are trivial.