Enhanc/Potential in links

[JulStraus]

This PR focuses on increasing the flexibility of Links. It incorporates several different concepts for links to allow for

1. differing input and output resources of links as well as specifying these directly (ae10474),
2. bidirectional links and nodes (113b8f3),
3. emissions of links (8110d8d),
4. OPEX of links (with both fixed and variable OPEX created at the same time) (166fe57),
5. capacity of links (9027a4d),
6. inclusion of new variables (f8d959a), and
7. investments in links (7c18c7e).

All introduced changes are only valid if the user specifies explicitly for their abstract or composite type that they should include them.

I did not update the documentation with additional information regarding the extension of Links yet. In practice, it only includes the new variables and the docstrings, but not how one can create new links.

[hellemo]

Looks good, this is an important step towards more unified building of models from both nodes and links.

I have thought a bit about the naming, and I currently lean towards using the same function for creating variables and constraints for nodes and links, and dispatch to different methods. Then we could get a nice top level loop that clearly communicats that we do the same for nodes and links (or where they differ), something like:

for elements ∈ (𝒩, ℒ)
     variables_opex(m, elements, 𝒯, 𝒫, modeltype)
     variables_capex(m, elements, 𝒯, modeltype)
     variables_capacity(m, elements, 𝒯, modeltype)
     variables_nodes(m, elements, 𝒯, modeltype)
end

I suggest we follow that up in a separate PR.

[hellemo]

I guess this is ok, but it's hard to read/make sense of and a pattern some users seen to copy from tests.

[JulStraus]

Yeah. In that respect, I think the people should focus instead on the examples. Note, that the changes in test_nodes.jl are mostly related to providing tests to existing functions (and the newly introduced unidirectional and bidirectional properties).

[JulStraus]

Looks good, this is an important step towards more unified building of models from both nodes and links.

I have thought a bit about the naming, and I currently lean towards using the same function for creating variables and constraints for nodes and links, and dispatch to different methods. Then we could get a nice top level loop that clearly communicats that we do the same for nodes and links (or where they differ), something like:

for elements ∈ (𝒩, ℒ)
     variables_opex(m, elements, 𝒯, 𝒫, modeltype)
     variables_capex(m, elements, 𝒯, modeltype)
     variables_capacity(m, elements, 𝒯, modeltype)
     variables_nodes(m, elements, 𝒯, modeltype)
end

I suggest we follow that up in a separate PR.

Generally speaking, I like the design of looping through everything. We could also split flow variables into two methods to be certain regarding the application. In theory, that should not be breaking as we do not export the functions.

There are however two things I want to stress:

• variables_nodes would be slightly confusing if we iterate through with links. We should rename it. Potentially variables_elements to be consistent?
• we should simultaneously consider which arguments we want to pass to the functions to be consistent. The only function we are currently exporting is variables_node which would be unaffected by the design. Hence, we can clean up the functions.

All of the changes should in my opinion be a separate PR, but with the same versions increase. That way, we do not introduce a version which we directly change again.