Refactor ForwardingRulesmanager

Refactor ForwardingRulesmanager

- Refactor flow entries database in order to remove synchronized methods which hit performance and
  to better accomodate cluster cache syncing:
  - Installed entries as a flat concurrent map of FlowInstallEntry key/elements
  - Modified FlowEntry hashCode function to take into account only the flow parameters which uniquely identify
    a flow entry: node, match and priority. Modified FlowEntryInstall hashCode function to only account install
    FlowEntry hash code.
  - Added a per node and per group index databases for efficiently access node or group flow entries in the flat map
  - Fixed bugs in MatchField hashcode (did not account MAC addresses), added Junit test for hashcode in Match,
    FlowEntry and FlowEntryInstall
- Have flow entries parameter classes implement Serializable so that FRM flow DB is synced across cluster cntroller nodes
- Added api to remove all flows part of a group, uninstallFlowEntryGroup()
- Added a event handler thread in FRM so that FRM does not hog switch handler thread on southbound events processing
- Changed the installation of startup configured static flows from synchronous to asynchronous flow install
- Modified FlowConfig.isValid() to return a status object, changed test code accordingly
- Fixed issue where internal generated static flows (the ones for proactive forwarding switches) were getting removed on container creation
- Fixed Flows GUI which was not showing static flow state correctly
- Minor coding style changes
- Changes tested with 2K static flows on two software switches with a custer of two controllers

Change-Id: Ic4c0167094988c0ebd44763e45541fe728d95ead
Signed-off-by: Alessandro Boch <aboch@cisco.com>