Additional Endpoint Documentation

[Elscrux]

Initial draft to get automatic documentation for our endpoints in place. A review would already be good at this point.
There are some things that might need a better approach.
For example, the way I convert objects to JSON for the documentation is quite messy with the required try/catch.
Also, there could definitely be more description texts to explain the API in more detail.
I'll probably add descriptions to all the parameters you pass in the future.

I also reworked how arguments are passed into the api tests. They should now test all solvers automatically and they should now use the examples from the documentation. The way I setup the examples was by adding a method to MetaSolver which can be overridden by all individual meta solvers. Do you think that's a good way to do it or would you prefer a more decoupled way?

[Elscrux]

@schweikart I've fixed pretty much everything you asked for, some points might need some discussion.
Can you review the changes I made for this? Especially concerning putting everything into the resources. Basically, it works the way that every problem type gets a folder in which they can store files with examples. Getting those examples is currently implemented in the special meta solvers everywhere and they are pretty much the same as they all use String problem input. But in case a problem wouldn't be of type string we'd need something else for this. That is why I didn't generalize this, but maybe we can improve this still.

The tests are still failing because #44 needs to be merged in this first to fix the usage of the type in SubRoutineDefinition

[schweikart]

Most things work nicely now but I have a few more suggestions and comments

[schweikart]

Our request examples always show "requestContent": null in each sub-solve request since we're using the same object for both our requests and our sub-solve-requests. We never use this attribute so it's kind of useless that we allow (and document) it. Should we maybe use another type for sub-solve-requests? Maybe a new SolverChoice as a supertype of SolveRequest?

{
  "requestContent": "namespace Sandwich\n\nfeatures\n    Sandwich {extended__}\n        mandatory\n            Bread\n                alternative\n                    \"Full Grain\" {Calories 203, Price 1.99, Organic true}\n                    Flatbread {Calories 90, Price 0.79, Organic true}\n                    Toast {Calories 250, Price 0.99, Organic false}\n        optional\n            Cheese\n                optional\n                    Gouda\n                        alternative\n                            Sprinkled {Fat {value 35, unit \"g\"}}\n                            Slice {Fat {value 35, unit \"g\"}}\n                    Cheddar\n                    \"Cream Cheese\"\n            Meat\n                or\n                    \"Salami\" {Producer \"Farmer Bob\"}\n                    Ham {Producer \"Farmer Sam\"}\n                    \"Chicken Breast\" {Producer \"Farmer Sam\"}\n            Vegetables\n                optional\n                    \"Cucumber\"\n                    Tomatoes\n                    Lettuce",
  "requestedSolverId": "edu.kit.provideq.toolbox.featuremodel.anomaly.dead.SatBasedDeadFeatureSolver",
  "requestedMetaSolverSettings": [],
  "requestedSubSolveRequests": {
    "sat": {
      "requestContent": null,
      "requestedSolverId": "edu.kit.provideq.toolbox.sat.solvers.GamsSatSolver",
      "requestedMetaSolverSettings": null,
      "requestedSubSolveRequests": null
    }
  }
}

We shouldn't work on this in this PR but do you agree that we should change this?

[Elscrux]

I rebased onto dev in order to merge the changes of the Cirq MaxCut Solver

[schweikart]

I've checked everything you've recently addressed, rebased and tried it out on my machine. Seems like this is finally ready to merge!