Adding default support for CORS in the REST paradigm

[arcfide]

You’ll notice that I set up the interface for the HandleCORSRequest function so that it will signal whether there was a CORS request in its result. The hope here is that by doing this, the same function might be able to be used for the REST handler as well, just that the REST handler will be able to “pass along” instead of returning right away as the JSON handler does. The question remains then, how to appropriately set the Methods allowed header for the REST defaults.

As an initial default, so that there are no API changes required, it might be good to just use the RESTMethods defaults. The HandleCORSRequest handler could be modified to take an optional left argument that contains the methods that will be supported. This might allow the handler to be more flexibly deployed on demand at different locations once the support methods are known.

My current vote for "fast to initial working" solution is to add an optional left argument to HandleCORSRequest that will set the methods, and then pass RESTMethods as that left argument when we call HandleCORSRequest from the HandleRESTRequest handler. [That's a lot of hands.]

[bpbecker]

CORS support for REST paradigm added in f2e0dc09ae5c032dfab468f24f4e8c84e26dbd91