Spelling

[jsoref]

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Description

Fixes misspellings identified by the check-spelling action.

The misspellings have been reported at https://github.com/jsoref/google-android-fhir/actions/runs/6288135984/attempts/1#summary-17073322067

The action reports that the changes in this PR would make it happy: https://github.com/jsoref/google-android-fhir/actions/runs/6288136028/attempts/1#summary-17073322270

Alternative(s) considered
Have you considered any alternatives? And if so, why have you chosen the approach in this PR?

Ignoring typos is always a possibility...

Type
Choose one: Trivial Bug fix

Screenshots (if applicable)

Checklist

• I have read and acknowledged the Code of conduct.
• I have read the Contributing page.
• I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
• I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
• I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
• I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
• I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

[jingtang10]

Thank you Josh!

How can we make this part of our continuous build/testing?

[jsoref]

@jingtang10: a commit close to jsoref@0029254#diff-aa48ce5bca2bfbf528400261b9c5a206f60410e880f71a80499efbe87ea236b2 could be added to the repository, I'd be happy to make such a PR (I tend to make a couple of adjustments -- especially setting up a feature for use in forks to ease configuration burden for contributors, and I need to incorporate a way to improve the handling of dependabot triggered PRs). But I like to talk to project owners to give them a sense of how things will work -- there are a bunch of tunables and it helps for people to understand what will happen before it's deployed. I'm available on Zulip if that's helpful.

The main choices are:

• report a ❌ status for the check (I generally do this, but one project opted out of this) -- this is configurable in the workflow file
• include a comment in the PR (I used to do this by default, but have mostly switched to relying on github status reports instead -- enabling the comment means giving the workflow pull-requests: write which people don't really like, and I agree) -- this is configurable in the workflow file
• the particulars of a footer to the report (advice.md and microsoft/terminal's implementation for some examples) that's appended at the end of reports when the tool finds problems -- this can be tweaked at any time in that file.
• any particular files to exclude (excludes.txt) -- this file (or a split of it) can be tweaked at any time.

[jingtang10]

Thanks - please feel free to send a pr. We can talk about the specifics in the pr.