Typos and clarifications to CAEP interop spec

[jogu]

1. Define short-lived access tokens format-neutrally (there's not a requirement I'm aware of for JWT access tokens to be used when you're doing SSF/CAEP)

2. Fix reason_admin - it was referred to as a string, but it's defined as an object

3. Fix inconsistencies

   • Strip redundant [RFCxxxx] prefixes from kramdown-rfc references
     (renders duplicated text otherwise)
   • Rename "Get Stream Status" labels to "Read Stream Status" to match
     the operation name used in the body and in SSF Section 8.1.2.1
   • Title Case headings consistently ("Network Layer Protection",
     "CAEP Specification Version")
   • Capitalize "SSF Receiver" consistently
   • Refer to device-compliance-change as a CAEP event type consistently
   • "### Spec Version" -> "### Specification Version"
   • Backtick status_endpoint to match formatting elsewhere
   • Add missing colon before sub-list of OAuth grant types
   • Reword "in the query parameters stated in" to "via the URI query
     parameter mechanism described in" (RFC 6750 terminology)
   • Capitalize "Resource Server" and "Section 3.1/4.1/4.4"
   • Drop stray trailing period from one Resource Server bullet
   • "use-cases" -> "use cases"
   • "POLL delivery" -> "Poll delivery" in reference comment

4. Grammar and typo fixes

- Fix "Sections 8.1.2.1" -> singular "Section"
- Replace `AddSubject` with "Add Subject" to match SSF spec
- Fix missing articles and prepositions in delivery/subject text
- Remove "using ... using" repetition in event signature requirement
- "separate entity than" -> "different entity than"
- "client credential grant flow" -> "client credentials grant"
- Hyphenate "short-lived" and reword exp/nbf claim definition
- Remove stray comma before MUST in OAuth scopes bullet
- Convert ambiguous MAY in Use Cases intro to MUST support at least one
- Replace dangling "These" antecedent in Security Considerations

I think the only potentially contentious change is replacing:

Implementations MAY choose to support one or more of the following use-cases in order to be considered an interoperable implementation.

with:

An implementation conforming to this profile MUST support at least one of the following use cases.

However I believe the intent remains unchanged, the language is just clearer now.