Use `ModComponentRef` instead of flat `extensionId` and `blueprintId` in panel entries

[twschiller]

What does this PR do?

• Use ModComponentRef instead of flat extensionId and blueprintId in panel runtime
  • Follows the principle that semantically coupled properties should be grouped
• Prep work for renaming associated to use official terminology
• Prep work for making mod id required in the runtime

Remaining Work

• [x] Fix broken tests

Discussion

• Including starter brick on the ref even though it's not strictly necessary in most parts, as it's only used in panel behavior of "show panel" preferring panels from the same mod. We could consider including a type that doesn't include the starter brick reference

Future Work

• Perform same refactoring for quick bar action registry, etc. NOTE: it's not required for SnippetShortcut because mod and starter brick is not currently used for functionality. (Although, in the future, we might consider clearing stale snippets when the user updates the mod in the Page Editor)
• Rationalize use of MessageContext in the runtime. The runtime should likely pass ModComponentRef through to BrickOptions vs. bricks having to read the context from the logger's MessageContext, which has weaker nullness constraints
• Rename fields in ModComponentRef: id (componentId?), modId, starterBrickId
• Rename uses of extensionId in exported panel runtime code
• Rename useDocumentPreviewRunBlock

For more information on our expectations for the PR process, see the code review principles doc