Feat/pyansys participants

[iboyd-ansys]

The aim here is to support a mode of using PySystemCoupling that is more integrated with participants that themselves have PyAnsys APIs.

The idea is that we have instances of the participant APIs (session objects) that support the setting up of their contribution to the coupled analysis as well as exposing methods to support connection to System Coupling and performing their part of the solve.

Such instances are added to a PySyC session simply by passing the session objects to PySyC. Internally the participant API is used to extract the information System Coupling needs, and the session is stored until a solve is commenced on the PySyC session. At that point, the participant sessions - which control instances of their own solvers - will be instruct to have their solvers to connect to System Coupling's solver and, once all are connected, will be instructed to start their solve. Work done in this PR is responsible for managing the participant sessions, together with System Coupling itself, in all of this.

One of the motivations for this, apart from it being a closer integration of the products in the general ecosystem, is to support cloud-based solves driven from Python. If the PyAnsys client is assumed to be driving its solver running as a container, and the PySystemCoupling server/solver is also running in its own container, it can be seen that a coupled solve can be managed from a PyAnsys "front end", where each participant session is responsible for starting its own container. This is in contrast with a more typical System Coupling run, which involves invoking Solve on System Coupling and, from there, it itself launches the participant processes - something that does not transfer so well to a containerised environment.

There are two main aspects to this PR:

1. Implementation of a new ParticipantManager which is responsible for holding the added participant sessions, extracting required setup information from them, and for managing the connect and solve calls on them in coordination with System Coupling's own solve.
2. Internal infrastructure needed to expose this functionality cleanly. The idea is that we want to overload the existing add_participant command so that it can continue to be used as it has been so far, but also supports being called with a single "participant session" argument. Similarly, when it comes to solving, we just want to be able to call solution.solve() as usual on the PySyC session object. To support this cleanly, some work has been done that builds on the existing "injected commands" functionality that allows a command that overrides an existing command to be injected, but also generates an internal form of the "normal" command that would have been generated. So, for example, the injected form of add_participant can examine its arguments and decide either to delegate to the new ParticipantManager or to call the internal command that is what add_participant used to be.

[codecov-commenter]

Codecov Report

Merging #177 (3be0b14) into main (7070a4a) will decrease coverage by 1.89%.
The diff coverage is 83.41%.

@@            Coverage Diff             @@
##             main     #177      +/-   ##
==========================================
- Coverage   91.59%   89.71%   -1.89%     
==========================================
  Files          29       32       +3     
  Lines        1511     1691     +180     
==========================================
+ Hits         1384     1517     +133     
- Misses        127      174      +47     

[iboyd-ansys]

Addresses issue #148