[vcpkg] Implement --editable

[ras0219]

--editable suppresses binary caching and source re-extraction for packages listed on the command line (similar to --head).

This fundamentally changes the port maintenance loop, so several example documents were updated. To avoid users having substantial changes suddenly destroyed by forgetting to pass --editable, "clean" sources have different extract locations.

The undocumented command build implies --editable.

See also #11204.

+@cenit +@Neumann-A as recent prolific contributors who can help confirm that this new inner-loop is still solid :)

[cenit]

Thanks for asking. I am not fully understanding the goal here, I will check it better in the weekend looking at the code

[Neumann-A]

So basicly we should start using vcpkg build or vcpkg install --editable if we want to do some changes to the build of a port.
It seems to work as intended. I just tested zlib and it seems to work as intended. hashes are completly different to master which will make merging a bit difficult if you are currently working on something.
The nice side effect is I don't need to copy the sources once as a baseline for git diff i can just use the *.clean folder

[ras0219]

Thanks for the feedback!

@cenit I'd be happy to answer any questions; it is also discussed a bit in https://github.com/ras0219-msft/vcpkg/blob/dev/roschuma/binarycaching-spec/docs/specifications/binarycaching.md#better-control-over-source-modifications

... hashes are completly different to master which will make merging a bit difficult if you are currently working on something.

I don't quite understand what you mean by this, could you explain a bit more?

[Neumann-A]

I don't quite understand what you mean by this, could you explain a bit more?

Seems like your master branch is just too outdated. I tested it with zlib and the initial build was with your master branch. It had a extracted source dir of 1.2.11-f690224aeb. I switched to your dev branch and got a extracted dir of 1.2.11-deec42f53b(.clean). I thus thought the hash has changed. Compared it now against other builds of zlib on my PC and saw that deec42f53b is the current one so the hash did not change and your master branch just needs updating to produce current hash values ;)

[cenit]

@ras0219 sorry I had no time to test your PR. Maybe also my workflow is different from what you describe (I usually do not work in the buildtrees folder, I have some scripts to automatically create patches from commits in outside folders, tracked so that patches can be pushed for upstream PR easily).
In any case, no objection to any feature that might help contributors do the best work they can