Correct inconsistent casing of fdc3.timeRange

[kriswest]

The fdc3.timeRange context type is inconsistently cased in the FDC3 docs and codebase, sometimes appearing as fdc3.timerange. This PR corrects it such that it appears as fdc3.timeRange in all cases.

Once approved the commit from this PR will need to be cherry-picked into a release/2.1.1 branch to release a corrected version of the 2.1 npm module.

[netlify]

✅ Deploy Preview for fdc3 ready!

Name	Link
🔨 Latest commit	89d5cca
🔍 Latest deploy log	https://app.netlify.com/sites/fdc3/deploys/667ec5be3c5be2000858eb97
😎 Deploy Preview	https://deploy-preview-1240--fdc3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[bingenito]

I added a reference from the task items for fdc3-dotnet 2.1 update to also fix this.

[bingenito]

Seems that a majority of the implementation was all lower so I wonder if it would have made sense to stick to that in all cases, but for consistency across the API the camel casing makes more sense. I expect most usage is through the enum/constant declarations that are exported and not string literal hardcoding.

[kriswest]

Seems that a majority of the implementation was all lower so I wonder if it would have made sense to stick to that in all cases, but for consistency across the API the camel casing makes more sense. I expect most usage is through the enum/constant declarations that are exported and not string literal hardcoding.

I agonized over that too - will the types have taken precedence or the examples and FDC3 workbench? In almost every cases there was a conflicting one on the same page or in the same schema. I decided to go with consistency with the rest of the standard in the end as I don't know that this type is heavily used as yet (it was originally created to support the fdc3.chart type). If we're ever going to correct it to be consistent, sooner is better.

I could add an admonition to the ref page for it, high;ighting the fact it had to be fixed...