Add Disk (from microsoft.compute/20200930) to generated resources

[babbageclunk]

What this PR does / why we need it:
This enables the Disk resource in code generation and adds a test that exercises creating, updating and deleting it.

Special notes for your reviewer:
The test framework is really nice now!

How does this PR make you feel:

If applicable:

• this PR contains tests

[codecov-commenter]

Codecov Report

Merging #1568 (80d9a57) into master (a4d3a51) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1568      +/-   ##
==========================================
+ Coverage   63.41%   63.43%   +0.01%     
==========================================
  Files         178      178              
  Lines       11739    11745       +6     
==========================================
+ Hits         7444     7450       +6     
  Misses       3628     3628              
  Partials      667      667              

Impacted Files	Coverage Δ
.../codegen/pipeline_add_cross_resource_references.go	91.76% <100.00%> (+0.62%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a4d3a51...80d9a57. Read the comment docs.

[matthchr]

I feel like these always look so clean!

@babbageclunk How was the experience, were there parts that were confusing/hard to understand? Did you look over the generated resource and see if it looked "reasonable"?

[babbageclunk]

How was the experience, were there parts that were confusing/hard to understand? Did you look over the generated resource and see if it looked "reasonable"?

Pretty straightforward, nothing difficult (might have been lucky with the resource, no weird warts on this one). I did look through the resource, it seemed sane, although lots of pointers which make it a little fiddly to construct types sometimes. One thing I think would be nicer in the generated output would be to split the files up differently. At the moment the types are lost in the surrounding ARM and storage conversion functions - it might be better to have the API types in one file, then ARM types, storage types, conversion functions, maybe webhooks (although there's not that much of them at the moment) in their own files. In general the API types are what people are going to be interacting with in code, everything else is machinery that should be transparent if things are working well.