Simplify deployment of a machine configuration definition

Summary of the new feature / enhancement

origninally posted in https://github.com/Azure/bicep/issues/17908

With the rise of DSC (formally known as PowerShell DSC) & WinGet as well as other well used Configuration technologies it would be beneficial to reduce the configuration for virtual machines to be able to point to a configuration file (directly or from a repository) like how I mention in this post of mine Wishes for Windows 12; the return of Windows Phone & **more**

The core change, whilst in bicep would be like this

resource vm 'Microsoft.Compute/virtualMachines@2023-03-01' = {
  name: vmName
  location: location
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_DS1_v2'
    }
    osProfile: {
      computerName: vmName
      adminUsername: adminUsername
      adminPassword: adminPassword
      windowsConfiguration: {
        enableAutomaticUpdates: true
        provisionVMAgent: true
        configurationName: 'Install-Git' // If this is a generic name like so then inside the configuration it should pick either dsc or winget on Windows
        configurationFile: 'https://raw.githubusercontent.com/Microsoft/Winget-Configurations/Install-Git.winget'
        // also support https://raw.githubusercontent.com/PowerShell/DSC-Configurations/Install-Git.dsc
        }
    }

or like this

 osProfile: {
      computerName: vmName
      adminUsername: adminUsername
      adminPassword: adminPassword
      linuxConfiguration: {
        configurationName: 'Install-Git' 
        configurationFile: 'https://raw.githubusercontent.com/PowerShell/DSC-Configurations/Install-Git.dsc'
        disablePasswordAuthentication: false
        provisionVMAgent: true
      }
    }

This could be extended to enable other configuration file formats (chef/ansible etc) & then install and kick off those agents as needed.

The benefit, is obviously less code, & the current need to add an extension that does this task.

I do realise the amount of work needed for this to happen, including redesign of how this would work in ARM and how reporting back should happen.

I realise this may be achievable with a module, but it would be nice if this was a native thing to the VM resource in bicep, of course needing this in ARM resource first & then could be implemented across other tooling like AzCli/AzPowerShell & all the other SDKs too, which I haven't raised an issue for this in those repos, as I feel it prob makes more sense to ask in here first.

Another potential added benefit (note this brought the configuration properties up a level as to allow for a single truely xplat configuration file) could also be a pointer to an interal ConfigurationRepo resource, that houses these like a fileshare etc or a private git repository etc etc

resource vm 'Microsoft.Compute/virtualMachines@2023-03-01' = {
  name: vmName
  location: location
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_DS1_v2'
    }
    osProfile: {
      configurationRepo: InternalConfigs
      configurationName: 'Install-Git'
      configurationFile: 'https://raw.githubusercontent.com/Microsoft/Winget-Configurations/Install-Git.winget'
         }
    }

Again I do realise the amount of work for this, and this is a be really nice to have to reduce authored code more than a absolute need.

Not sure who across other Azure Teams would need to input other than the Machine Config team

Proposed technical implementation details (optional)

No response

No repository file, test, or entry point is identified. First review the DSC v3 project scope and determine whether Azure VM, Bicep, and ARM support belongs here or in another Azure repository. Done would require an agreed design plus a defined implementation and validation path.