Continue new Loop search approach

This continues @kbenne work to use graph theory to search for demand and supply components. He implemented a depth first search for demand components only but now it does supply components as well.

This also changes how edges are found from @kbenne first implementation. Now each HVACComponent has a virtual method ::edges() that outputs the immediate downstream component(s). So this logic is now within each HVACComponent derived object (or vertex) instead of within Loop. Now we don't need to optionalCast to different types to get the outletModelObject (or whatever the downstream API call is) and allows us to avoid PortLists entirely.

I also took the depth first search algorithm and applied it to find a single specific object by Handle. Basically, it will search all paths until it finds and returns the object or returns none. 

I had to pass a boolean 'isDemandComponent' parameter in ::edges() because WaterToWaterComponent and WaterToAirComponent downstream component API call differs depending if the object is a supply or demand component.

@kbenne @macumber My only question is on the naming of the boolean parameter. I don't know if 'isDemandComponent' is best? 'isDemandLoop'? 'isDemandComponents'?

If you both could look over and test out this branch that would be great. I ran unit tests, integration tests, and OS App GUI spot checking as well.

I plan to implement caching in a new branch in hopes of speed increases.