Improve handling of forecast variables

[dhblum]

Currently, GET /forecast returns all data for all forecast variables, which for large data sets leads to a hit on memory and computational time. There is also no documentation in the test cases of which forecast variables are available. This issue is to propose the following improvements:

• Treat getting of forecast data similarly to /results. That is, add an argument that requires specification of the variable wanting to be forecasted and return data for that variable only. One even more backwards-incompatible thought could be to remove the /forecast_parameters API endpoint and replace with parameters horizon and interval upon retrieving a forecast for a particular variable. These changes combined would then change the forecast API endpoint to resemble the PUT /results API very closely as PUT /forecast with arguments point_name=<string>, horizon=<value>, interval=<value>.
• Have a mechanism to add descriptions and units to forecast variables (perhaps another json included in the test case FMU), include these in a documentation section of test cases (similar to control inputs and measurements), and implement a GET /forecast_variables acting similarly to GET /inputs and GET /measurements to retrieve this information programatically.

[dhblum]

Initial implementation at https://github.com/ibpsa/project1-boptest/tree/issue356_forecastPoints. Still needs:

• Update error handling
• Update documentation for twozone_apartment_hydronic test case to include forecast points
• Add/update unit tests
• Update release notes
• Update readme
• Review

[dhblum]

Closed by #508.