Support mixed security context configurations

Summary of the new feature / enhancement

A configuration may require parts to be elevated and also parts to be restricted. This is already supported for the whole doc via metadata, but this needs to be extended to specific resources.

Proposed technical implementation details (optional)

Initially, if a configuration requires mixed, we should require that the user be elevated and during execution, dsc creates a restricted process to run the resources that specify restricted.

Later, if a configuration requires mixed, dsc can detect this and prompt at the start (UAC on Windows and sudo on non-Windows) to spawn a child dsc process that is elevated that actually executes the configuration and handles restricted the same as the initial implementation above.

One potential technical challenge is reading/writing standard io across elevated and restricted processes.

The issue does not name files or tests; start by tracing how dsc executes configurations and resources, including the existing whole-document security metadata. Define how mixed configurations identify restricted resources and how elevated and restricted processes exchange standard I/O. Done means both elevated and restricted resource execution are supported without changing the intended security context.