Add 'localDeploy' experimental feature, base extension nuget library

[anthony-c-martin]

• Add wiring for "localDeploy" experimental feature. The feature doesn't do anything yet as of this PR.
• Add "Bicep.Local.Extension" nuget package to contain logic for C# extension authoring.
• Add "extension.proto" to defined the contract between client (Bicep) and extension in gRPC.
• Support unpacking of provider packages to the local file system to the ~/.bicep cache folder.

The full spec is available here - unfortunately only available to Microsoft employees currently.

Microsoft Reviewers: Open in CodeFlow

[github-actions]

Dotnet Test Results

    65 files   -     34      65 suites   - 34   22m 59s ⏱️ - 8m 39s
10 876 tests  -     20  10 875 ✅  -     20  1 💤 ±0  0 ❌ ±0 
25 648 runs   - 12 820  25 646 ✅  - 12 819  2 💤  - 1  0 ❌ ±0 

Results for commit a7998b2. ± Comparison against base commit ba1e9f8.

♻️ This comment has been updated with latest results.

[github-actions]

Test this change out locally with the following install scripts (Action run 9369999284)

VSCode

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-vsix.sh) --run-id 9369999284

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-vsix.ps1) } -RunId 9369999284"

Azure CLI

• Mac/Linux

  bash <(curl -Ls https://aka.ms/bicep/nightly-cli.sh) --run-id 9369999284

• Windows

  iex "& { $(irm https://aka.ms/bicep/nightly-cli.ps1) } -RunId 9369999284"

[jeskew]

Maybe out of scope for this PR since the replaced line was using .Single(), but does this result in an understandable error message if a template author refers to an artifact that violates this expectation?

[anthony-c-martin]

I think the code so far is assuming packages to be well-formed - this is something I think we'll need to improve.

[jeskew]

Is the URL actually used since the channel is connecting over a domain socket? If it isn't, I might make it something unresolvable like never://this-should-not-be-used.wtf so that the whole thing fails fast and the FQDN jumps out in log messages in case this ever does not work as expected.

[anthony-c-martin]

This is taken from the official docs: https://learn.microsoft.com/en-us/aspnet/core/grpc/interprocess-uds?view=aspnetcore-8.0. I'll add a comment here to explain this, as it's not very clear from the code that it's unused. I'd rather stick with localhost than make up a domain which may confuse people further - especially if I don't think we'd hit this in production.

[jeskew]

I'd be slightly more concerned about the failure mode -- http://localhost is just as likely to connect to the wrong thing as it is to fail to connect, which I would think would be more confusing for users (e.g., it'd be reported as something exotic like a GRPC protocol error or validation exception).

This is a pretty far-fetched scenario, though, so feel free to ignore.

[jeskew]

Had one question about testability but am not sure if it's applicable in this context. Otherwise LGTM