Simplify arc creation through connect_to method on port

[avdudchenko]

Fixes # .

• This adds a connect_to method to port to simplify arc creation in models

Summary/Motivation:

Currently in many models we use Arcs to connect multiple units/blocks together. In most IDAES/WaterTAP flowsheets or models this becomes very tedious as user must create, name, and track arcs as well as manually propagate them.

• User needs to manually remember which arc is which and manually propagate them between unit initialization steps
• This makes model code difficult to read and complicates flowsheet creation process

For example below shows an example, but one key thing to remember is in real flowsheets. the location of arc names and definitions would be separated by a hundreds of lines of code between arc creation and actual propagation occurs (example here:
arc creation and arc propagation by which point user probably forgot what the actual arcs are for and where they are connected (especially new users or developers)

m.block_a.outlet_port= Port()
m.block_b.inlet_port= Port()
m.block_a.block_a_to_block_b_arc=Arc(source=m.block_a.outlet, destination=m.block_b.inlet)

Then to propagate
propagate_method(m.block_a.block_a_to_block_b_arc) # If arc is not clearly named, its impossible to figure out whats its for. 

The connect_to method is intended to simplify arc creation and management work flow where user can simply connect two ports with simple connect_to call. This is not intended to replace Arc method, but be a parallel approach to connecting ports.

New approach

m.block_a.outlet_port= Port()
m.block_b.inlet_port= Port()
m.block_a.outlet.connect_to(m.block_b.inlet) # Clear what is connecting to where

# To propagate the user can simply then go 
propagate_method(m.block_a.outlet.get_connections) # clearly which connections are being propagated. 

Example of this workflow can be seen here

The objective of this PR is start a discussion on this workflow and get feedback on issues that might need to be addressed before implementation.

Some known concerns:

• automatic arc naming based on ports can lead to collisions - attempted to address this by getting full port name which should include port.
• There is a circular import issue as Arc import Port method, to circumvent this, connect_to import Arc at call. This is not ideal but impossible to address with out major reorganization of Arc or Port methods. I also do not wish to create a new "Port" object so we do not have to rebuild upstream models to access this method.

Changes proposed in this PR:

• add connect_to method to Port
• add get_created_arcs method to Port

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[jsiirola]

At the dev call we discussed splitting this PR in half, keeping the connect_to API extension, but deferring the get_connections to a later PR. The concern was that the proposed implementation of get_connections was both fragile (e.g., cloning partial models could cause consistency errors as the outgoing connections might not get updated correctly) and introduced circular references in the model.

We tossed around an idea of exploring an alternate implementation of get_connections by creating a utility (class) that would take a model and interrogate all the Arcs to collect the full port/arc connectivity graph. That object could then support the get_connections() (and potentially other logic like stream tearing),

We are adopting a new review process where we convert PRs that are "waiting on the author" back to "draft" (to signal the PR state to both the author and the dev team). Please use the "Ready for review" button to signal the developers when it is time to get the PR back into the review queue.