Add dynamic runtime resource parsing helpers

## Summary

Add a root-level runtime API for validating payloads whose `resourceType` is only known at runtime.

This should build on the existing per-release `resourceType` dispatch tables already used by generated `Bundle.entry[].resource` and `DomainResource.contained` validation. Do not introduce a second handwritten resource registry.

## Proposed API direction

Expose the first version from the package root:

```ts
import { parseResource, safeParseResource } from "fhir-zod";
```

Keep the release explicit.

Recommended v1 helper set:

- `safeParseResource(version, payload)`
- `parseResource(version, payload)`

`getSchemaForResourceType(version, resourceType)` can be evaluated during implementation, but it should not be assumed to be part of the minimum v1 surface.

## Behavior requirements

- reuse the existing release ids: `stu3`, `r4`, `r4b`, `r5`
- dispatch by `payload.resourceType`
- preserve familiar Zod behavior instead of wrapping errors in a custom error type
- keep failure semantics aligned with the existing generated full-resource validation where possible

Required failure cases:

- input is not an object
- missing `resourceType`
- non-string `resourceType`
- unknown `resourceType`
- known `resourceType` with invalid payload shape
- unknown release argument should fail immediately as library misuse

## Implementation notes

- prefer root-level helpers, not release-scoped helper duplication
- if needed, expose a stable accessor for the generated per-release resource schema map
- do not add a handwritten map of resource names to schemas

## Tests to add

- succeeds for a valid known resource
- fails when input is not an object
- fails when `resourceType` is missing
- fails when `resourceType` is not a string
- fails when `resourceType` is unknown
- fails when the payload shape is invalid for a known resource
- preserves issue paths from the underlying resource schema
- honors `configureFhirString` the same way direct schema parsing does

## Acceptance criteria

- consumers can validate runtime-selected resources without writing their own `switch` on `resourceType`
- release remains explicit in the public API
- runtime lookup uses the existing generated dispatch tables as the single source of truth