Improve disk space use for Windows jobs on GHA

[mgorny]

Comment:

xref conda-forge/pytorch-cpu-feedstock#409

PyTorch started taking a lot more space to build recently. While trying to workaround it by increasing the CIrun runner size, two problems were noticed:

1. Builds are performed in c:\bld rather than (unless I'm mistaken) the much larger d:\ partition. Effectively, choosing a larger builder had no effect, since it did only increase the d:\ partition which was used for miniforge but not the c:\ partition which was used for build.
2. The partitions don't take up all the available space, so increasing the builder disk size doesn't immediately benefit the builds.

I've tried modifying the files in the feedstock to force d:\bld instead but to no avail. Instead, for now, we've used the snippet in conda-forge/pytorch-cpu-feedstock@a6b03c9 (as suggested by @aktech, thanks a lot!) to resize the c:\ partition to use the additional space available.

Could we:

1. Include this (or a similar snippet) in the templates, to use all the space available in the runner?
2. Look into using d:\ for build (and then resizing it instead), since it seems to be the larger partition?

[h-vetinari]

We currently don't have a way to choose CONDA_BLD_PATH on GHA, as the config

azure:
  settings_win:
    variables:
      CONDA_BLD_PATH: C:\\bld\\
      MINIFORGE_HOME: C:\\Miniforge

is specific to azure, c.f.

conda-smithy/conda_smithy/templates/azure-pipelines-win.yml.tmpl

Lines 51 to 56 in 635f55d

	- script: |
	call ".scripts\run_win_build.bat"
	displayName: Run Windows build
	env:
	MINIFORGE_HOME: $(MINIFORGE_HOME)
	CONDA_BLD_PATH: $(CONDA_BLD_PATH)

We can definitely expose something along those lines for GHA as well (this already came up in #2347 too), but we should be mindful about just adding on more stuff that should in principle be universal across feedstock providers: #2349

Disk resizing is probably not universal (or maybe it is... even if becomes a no-op), but we should definitely add an option for that if we need it for the pytorch feedstock.

[mgorny]

Disk resizing is probably not universal (or maybe it is... even if becomes a no-op),

My thinking was that it would just be a no-op if there's no extra space to be taken, and that it will harmless in general.

[h-vetinari]

@mgorny, this would be good to have to avoid having to do manual fixups on the pytorch feedstock after every rerender

CC @jaimergp