Add section for `facts` to allow retrieving existing resources to be used later

Summary of the new feature / enhancement

It's possible a resource supports export, but not set and with an upcoming change, get will be called when attempting an export if the resource doesn't support it directly. Now imagine you've exported current state (which might even include the OSinfo resource which only supports get).

I can imagine a scenario where a user wants to turn around and deploy this exported config as set, but it will fail once it hits a resource that doesn't support set.

Proposed technical implementation details (optional)

A potential solution is that the user can either opt-in or opt-out of the default behavior of whether set ignores (or warns) on resources that don't implement set rather than outright error and fail.

In this case, a resource that ONLY supports get is effectively read-only. So I would argue that the user should understand this and thus read-only properties are ignored instead of erroring. In which case, the default behavior is to ignore (and if not explicitly opt-ed out emit a warning message) and the user can apply metadata per resource or at document level to explicitly opt-in or opt-out of ignoring:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
contentVersion: 1.0.0
resources:
- metadata:
    Microsoft.DSC:
      setNotImplemented: Ignore | Warning | Error
  type: Microsoft/OSInfo
  name: Microsoft/OSInfo-0
  properties:
    $id: https://developer.microsoft.com/json-schemas/dsc/os_info/20230303/Microsoft.Dsc.OS_Info.schema.json
    family: macOS
    version: 15.6.0
    bitness: '64'
    architecture: arm64

No files, tests, or entry points are named. Start by locating the existing export, get, and set handling and the document metadata model, then determine how read-only resources such as Microsoft/OSInfo should be treated. Done means the proposed behavior is defined for exported configurations and its warning or error outcomes are covered by tests.