Generalize meter/counter handling in TdiTableManager

[ffoulkes]

Is your feature request related to a problem? Please describe.
Half a dozen of the functions in TdiTableManager perform specialized processing for specific meter or counter types. In each case, the function calls a method grafted into P4InfoManager to obtain the "resource type" for the object it is processing. It uses a series of if/then/else blocks (the equivalent of a switch statement) to determine what to do, based on the resource type.

This construct -- repeatedly switching on a type in order to selecting the processing to be done on an object -- cries out for the use of polymorphism. (See heuristic G23 in Clean Code, "Prefer Polymorphism to If/Else or Switch/Case".)

Some (if not all) of the code depends on a customized version of P4Runtime. TdiTableManager is common to all TDI targets, so all targets are subject to a dependency that may not apply to them. This is also undesirable.

Describe the solution you'd like
The proposed solution is as follows:

Processing is as follows:

1. TdiTableManager creates a TdiResourceManager and registers it with P4InfoManager.
2. If a P4ResourceManager is registered, P4InfoManager invokes its RegisterResource() method for each P4 object it processes.
3. TdiResourceManager creates a single TdiResourceType instance for each unique resource type it encounters. It stores a pointer to the object in a hash map whose key is the resource identifier.
4. Each method in TdiTableManager that needs to perform resource-specific processing on an object calls TdiResourceManager::FindResourceTypeByID() to obtain a pointer to the associated TdiResourceType. If the pointer is null, the method does nothing. Otherwise, it invokes the ResourceType method associated with the TableManager method.
5. The TableManager creates a TdiResourceFactory object using a TdiTableFactory, and passes it to TdiResourceManager, allowing each target to support its own set of resource types.

Nothing in the design constrains TdiResourceManager to using the same instance of TdiResourceType for all resources in that class. If there's a compelling need to store instance-specific information, or to maintain instance-specific state, this can be implemented in TdiTableFactory with no impact on the ResourceManager.

Describe alternatives you've considered
A less general solution has been proposed to deal with the ES2K-specific packet meters. See issue #290 for details.