Unify ecflow server

[trygveasp]

Describe your changes

Create objects containing the ecflow environment/server and the scheduling information.

I hope I can make it non-breakable with old suite configuration.

closes #41

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist before requesting a review

Testing

• I have tested this on ATOS using the atos_bologna.toml configuration in the latest version of Tactus-test-runner
• I have tested this on LUMI using the lumi.toml configuration in the latest version of Tactus-test-runner

For further information see the development guide

Code quality

• My change follows the best practices for this project.
• My local environment is correctly initialised as described in the README file.
• My branch is up-to-date with the target branch - if not update your fork with the changes from the target branch (use pull with --rebase option if possible).
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation and docstrings to reflect the changes
• I have added tests that prove my fix is effective or that my feature works
• I have ensured that the code is still installable with poetry after the changes and runs
• I have requested one or more reviewer(s) and an assignee (assignee is responsible for merging). At least one reviewer has accepted to review.

Checklist for reviewers

Each PR comes with its own improvements and flaws. The reviewer should check the following:

• the code readable
• the code well tested (checked coverage report)
• the code documented
• the code easy to maintain

Author checklist after completed review

• I have added a line to the CHANGELOG describing this change (in section
  reflecting type of change, for example "bug fixes", add section where
  missing)

Checklist for assignees

• PR is up to date with the base branch
• the tests passing
• author has added an entry to the changelog (and designated the change as added, changed or fixed)
• the PR has been approved by all the reviewers, that accepted to review.
• Once the PR ready to be merged, squash commits and merge the PR.

Tag possible reviewers

You can @-tag people to review this PR in addition to formal review requests.