Add PortModules to core API

[feldergast]

Please describe the new features with any relevant use cases.

PortModules will be added to the core interfaces. The PortModule will be able to intercept Events on both send and receive.
This functionality could be useful for simulating "noisy channels", where errors may be introduced during communication.

Describe the proposed solution you plan to implement
The implementation will be similar to and encapsulate the functionality of the EventHandlerProfileTool interface (i.e., the EventHandlerProfileTool will inherit from PortModule). The major change to the API will be that the function calls will return Event* instead of void. This will allow the PortModule to modify or drop the event, if desired.

Testing plan
A test using PortModules will be developed and will test the cases of dropping and modifying Events.

Additional context
The major challenge is making the EventHandlerProfileTool inherit from both PortModule and ProfileTool. The main issue here is how to handle the ELI information for the combined class.

[bpswenson]

Current implementation is here: https://github.com/bpswenson/sst-core/tree/portmod.
Example port module that drops events on either send or receive: https://github.com/bpswenson/sst-core/blob/portmod/src/sst/core/portModules/randomDropPortModule.h

Example usage:

atlanta = sst.Component("Atlanta_ATL", "AirportSim.Airport")

atlanta.addParams({
	"name" : "Atlanta_ATL",
        "num_connectors" : 1,
        "num_planes": 2
})

milwaukee = sst.Component("Milwaukee_MKE", "AirportSim.Airport")
milwaukee.addParams({
    "name" : "Milwaukee_MKE",
    "num_connectors" : 1,
    "num_planes": 1
})

atl_mke = sst.Link("atlanta_milwaukee")
atl_mke.connect((atlanta, "airport_connector_0", "4s"), (milwaukee, "airport_connector_0", "4s"))`

atlanta.addPortModule("airport_connector_0", "sst.portmodules.random_drop_port_module", {
    "drop_prob": 0.9,
    "verbose": "true",
    "drop_on_send": "true"
})

[feldergast]

In general I think the code structure looks good. We will need to figure out how to make these checkpoint able. We are not planning to include profiling tools in checkpoints, but these reuse the same data structures and will need to go into the checkpoint. I wouldn't worry about that for getting this code in, we'll deal with that as the checkpointing support continues to evolve. The only other thing I noticed is that verbose print-outs need to use the Output class instead of cout.

At this point, the code will need a rebase, but I think it looks good and it can moved onto a PR if things are ready.

[feldergast]

With the latest addition of AttachPoints, PortModules will now be built on top of AttachPoints, instead of directly on top of the profiling point APIs. This will better separate the functionality of the various types of tools installed in AttachPoints. In particular, PortModule will inherit from Event::HandlerBase::InterceptPoint and Link::AttachPoint, and will provide functions to control whether a specific instance of a PortModule is installed in both places, or just in one.

[feldergast]

Initial support for PortModules was added in #1201