Create unified story for samples in our repo

[heaths]

We have a number of different ways of doing samples in Azure/azure-sdk-for-net, as seen in /samples, /sdk/keyvault/samples, and some SDKs' individual samples directory. The /samples directory is effectively outside the scope of most of what /eng/*.{props,targets} files do, but we still want:

1. Some (all?) analyzers to run to make sure the code is good.
2. The test infrastructure to optionally run the samples to make sure they actually work.
3. A way to use and deploy shared source if necessary. I did this in /sdk/keyvault/samples/sharelink but it's incredibly hacky.

Basically, it would be ideal if we can get some of the benefits like analyzers and test infrastructure without the assertions like even specifying our own PackageReference/@Version attribute, which customers downloading sample code would need (our @OverrideVersion will not be effective).

[kurtzeborn]

I know the current thinking is to keep samples out of smoke tests, but if that changes, please coordinate with @ckairen and @benbp on the smoke test story.

[pallavit]

@heaths I believe we unified our story with testable samples, do you still see discrepancy in the newer SDKs? If so could you please share what the unified experience would look like?

[heaths]

I helped drive testable samples in the first place. :) This is actually different. Only SDK-specific samples get the benefits of stuff under eng/ but root- or service directory-level have to get...creative.

That said, unless @jsquire - who has also been involved in various discussions of this nature - has any strong desire that we should invest in this area, this has been open for a couple years and we still haven't acted on it, so I agree it's probably not high-priority. sdk/keyvault/samples I've pretty much dealt with - though at great expense - and can hopefully save others time by copying patterns I established there.

[jsquire]

@heaths: I'm good with closing this out. The patterns from KeyVault have also been used by packages in the messaging ecosystem and the overall patterns for enabling in-repo and stand-alone use have held up well.