proposal: make a bunch of stuff inlinable

Start by auditing the public APIs named in the proposal: FHIRPrimitive and its companion types, FHIRType-derived classes, conversion extensions, and operations such as ResourceProxy.get. Review which trivial operations can safely be marked @inlinable and which should remain excluded. Done means the appropriate public APIs are inlinable without exposing unsupported implementation details, with the proposal's performance goal addressed.

Current Situation

effectively none of the APIs in FHIRModels can be inlined by apps/packages using the FHIRModels package.
this is can become very painful, especially e.g. when creating a lot of FHIRPrimitives where the underlying value is just a copy of the input (eg: FHIRString, FHIRURI, FHIRDecimal, etc.)

context: our application's primary use case for FHIRModels is creating Observations (and via that a bunch of other FHIR types), which then get JSON-encoded and uploaded to a server. (we also sometimes use the package to decode and inspect data, but that's a tiny minority of our usage.)
it's not uncommon for our app to create millions of FHIR samples per day; as a result the lack of inlinability does actually have a significant and easily noticable impact on our app's performance.

Suggested Solution

i'd like to propose Apple consider marking as much of the FHIRModels package's public API as possible as @inlinable:

• all trivial operations on FHIRPrimitive and its companion types (FHIRString, FHIRURI, FHIRDecimal, FHIRInteger, etc)
  • initializers
  • equatable implementations
  • other operations (eg: stuff like Base64Binary.data(using:), FHIRPrimitiveProtocol.extensions(for:), Instant.asNSDate(), etc)
  • all of the asFHIR{Type}Primitive() extensions
• all initializers on FHIRType-derived classes
  • including the convenience initializers; since they typically default all of their parameters to nil, my understanding is that the compiler would end up emitting code only for setting those properties that actually are passed into the initializer, but i'll need to double-check that)
• all trivial operations on FHIRType and its derived classed (eg: the FHIRAbstractResource hash and equality operations)

there are some things that probably don't make sense to inline (ResourceProxy.get comes to mind; i'm not sure how the compiler would handle that)