Allow modeling style inputs to analyze endpoints
Allow modeling style inputs to analyze endpoints

Previously the /analyze/ endpoints accepted shapes as GeoJSON in
the POST body, and other parameters were provided in the query.
This was done because the original /analyze/ endpoints did not
take any parameters, and when the time came to add some, we did
not want to disrupt existing users, so added them in the query.

The /modeling/ endpoints require more complex input, thus always
accepted a JSON object as the POST body, which included all other
paramteres as well. This manner allows for more complex parameters,
such as layer_overrides, which is an object itself, and also for
more parameters to be added in the future.

Having two endpoints that work similarly but differently is confusing.
So we align them. But this can potentially break the workflow of
existing users.

Thus, we add the ability to accept /modeling/ style inputs in /analyze/
endpoints, without taking away the ability to accept old /analyze/ style
inputs. If the user gives old style inputs, then we still process them,
but include a message in the job submission output that alerts them
of deprecation warnings. If the user gives new style inputs, then we
don't give the deprecation warning.

WikiWatershed/model-my-watershed,WikiWatershed/model-my-watershed,WikiWatershed/model-my-watershed,WikiWatershed/model-my-watershed,WikiWatershed/model-my-watershed