CFFDRS API : Local integration with WPS API proof of concept

**Describe the task**
We need to establish if an API will be performant enough. This task involves switching out a single function that is heavily used in the Fire Behaviour Calculator

**Acceptance Criteria**
- [ ] Switch ISICalc from local to remote in WPS API.
- [ ] Establish if CFFDRS API is performant enough
- [ ] Establish if making adjustments in how we use CFFDRS could make it performant enough (e.g. instead of making hundreds of individual calls, making a single call)
- [ ] Feature toggle to switch WPS API between CFFDRS using rpy2 and using CFFDRS API (allows merging code in current state before completing remaining tasks for full switchover)
- [ ] Implement feature toggle for .ISICalc (so when CFFDRS API toggle is configured, the local call using rpy2 will be replaced with a REST call to the CFFDRS API)

**Additional context**
- Spinning up R is very slow, and blocking, it blocks other calls to the same thread in causing timeouts in calls entirely unrelated to anything that uses R. We need to isolate all R related issues in it's own process.
- We're very intentionally implementing .ISIcalc first. It's called repeatedly from get_critical_hours, and should expose performance issues re. using a web service early on.
- CFFDRS API endpoints to take vector inputs NOT scalar
- Depending on completing #2275

Start with the WPS API path that calls ISICalc from get_critical_hours, then trace the existing rpy2 call and the CFFDRS API's vector-input endpoints. Compare local and REST behavior and measure repeated scalar versus batched calls; done means configurable toggles select either implementation, performance is assessed, and the remaining dependency on #2275 is resolved.

Written by the indexing model from the issue text.