Add support for resources to be represented as hash map as part of ARM Language 2.0

[andyleejordan]

Resolves #1193 (at least what we know is required experimentally).

Okay so I tried a bunch of different ways and settled on this being the simplest approach. In short, a custom serde deserializer function let's us take resources as either an array or an object and produce what the existing implementation expects: a Vec<Resource> such that after the initial deserialization, nothing else needs to change. This means that later ordering should work (though when I tested dependsOn in Bicep, I got a different error).

I can at least now pass through this Bicep directly to DSC and it gets to the point that it attempts to execute the resource:

extension dsc
targetScope = 'desiredStateConfiguration'

resource myEcho 'Microsoft.DSC.Debug/[email protected]' = {output: 'Hello world!'}

which produces this ARM/JSON:

{
  "$schema": "https://aka.ms/dsc/schemas/v3/bundled/config/document.json",
  "languageVersion": "2.0",
  "contentVersion": "1.0.0.0",
  "metadata": {
    "_generator": {
      "name": "bicep",
      "version": "0.38.33.27573",
      "templateHash": "9007474339958309780"
    }
  },
  "imports": {
    "dsc": {
      "provider": "DesiredStateConfiguration",
      "version": "0.1.0"
    }
  },
  "resources": {
    "myEcho": {
      "import": "dsc",
      "type": "Microsoft.DSC.Debug/[email protected]",
      "properties": {
        "output": "Hello world!"
      }
    }
  }
}

Note that there is also a slightly different variation which uses extension(s) instead of import(s) with a particular experimental feature flag that, as of right now, is necessary for the end-to-end demo to work. Those are also added and ignored. See Azure/bicep#18365

Perhaps we should gate this behind a feature-flag, but between this and publishing a basic version of the Bicep extension to an MCR, we can resume demos but with fancy IntelliSense and working versions!

For the fields noted as irrelevant, I sure would like to use #[serde(skip)] but it is incompatible with deny_unknown_fields. Perhaps we should revisit that Serde flag, possibly using the linked workaround with IgnoredAny and warnings instead of failures.

[andyleejordan]

@SteveL-MSFT Pester test added for the latest ARM generated by Bicep. Note that Azure/bicep#18365 will be required to use "just" the desiredStateConfiguration Bicep experimental feature. In which case the extensions/extension fields are replaced by imports/import.

[andyleejordan]

Just a heads up that as noted in the PR, Bicep has and will likely continue to add new fields (especially when using experimental features) and since we're setting #[serde(deny_unknown_fields)] we're allowing that to break us rather than warn us. I highly recommend we switch from that to an ignore and warn approach instead. /cc @michaeltlombardi

[SteveL-MSFT]

@andyleejordan I'm in agreement that we should relax the strict validation, but then we'd need to warn about unknown new properties. That can be a separate PR, can you open an issue for this?

[andyleejordan]

CI is failing because the PowerShell Gallery is down due to the Azure Front Door outage.