Update TulipaConstraint to allow attaching more constraints to the same indices table

[abelsiqueira]

With the idea of allowing multiple constraints per indices table, this links the indices to the constraints. It also creates a function attach_constraint! to help keep things in check.

It fails the avoid fields with abstract types recommendation (ConstraintRef has three parametric types), so it might be unnecessarily slow.
I see two solutions:

1. Don't store the container at all, just the names. This is probably sufficient and cleaner.
2. Store the multiple types that ConstraintRef can have, either with multiple fields, dict of dicts, or more complicated structures. I don't like this idea because it makes the code more complex and involves more JuMP specific things. However, if the container for the containers is required, this is necessary (but so I far I don't see it being required).

EDIT: I added a commit with option 1 implemented.

@datejada, what do you think?

Closes #957

[codecov]

Codecov Report

Attention: Patch coverage is 88.88889% with 4 lines in your changes missing coverage. Please review.

Project coverage is 95.42%. Comparing base (28a33b4) to head (78ee95f).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/structures.jl	78.94%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #959      +/-   ##
==========================================
- Coverage   95.73%   95.42%   -0.32%     
==========================================
  Files          29       29              
  Lines        1008     1027      +19     
==========================================
+ Hits          965      980      +15     
- Misses         43       47       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Benchmark Results

	28a33b4...	78ee95f...	28a33b4.../78ee95fac56641...
energy_problem/create_model	41.9 ± 1.3 s	42.2 ± 1.6 s	0.993
energy_problem/input_and_constructor	15.4 ± 0.33 s	15.3 ± 0.42 s	1
time_to_load	3.97 ± 0.013 s	3.96 ± 0.017 s	1

	28a33b4...	78ee95f...	28a33b4.../78ee95fac56641...
energy_problem/create_model	0.664 G allocs: 21.1 GB	0.658 G allocs: 20.9 GB	1.01
energy_problem/input_and_constructor	0.0518 G allocs: 1.97 GB	0.0518 G allocs: 1.97 GB	1
time_to_load	0.159 k allocs: 11.2 kB	0.159 k allocs: 11.2 kB	1

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

[datejada]

@abelsiqueira option 1 is preferred, and I see you started with it. So, Thanks!

[abelsiqueira]

Thanks for the review @datejada, I commented on all of them

[datejada]

Hi @abelsiqueira, thanks for the PR. There were some comments and questions during the review, but generally speaking, it looks cleaner with the changes, and I like the approach. Thanks.

[abelsiqueira]

Thanks for the review! I've updated the PR with the error messages and further comments. Let me know what you think

[datejada]

Great! Thanks for the changes; I am approving this PR. You can merge after all the checks have been done.

[abelsiqueira]

Thanks! I'll merge after the benchmarks run and rebase #642