Detect symlink creation capability on Windows

[HertzDevil]

Explicitly detects the presence of Developer mode or the ability to enable SeCreateSymbolicLinkPrivilege, and errors immediately upon running any command that potentially fetches dependencies (build, install, lock, outdated, run, update). This reduces the chances of leaving the lib directory in an incomplete state in the middle of those commands.

The old exception handler for symlink failures is now gone; if an unhandled exception shows up, that means this PR is not exhaustive enough.

[straight-shoota]

LGTM.

But it's quite a bit of very platform-specific code for stuff that a high-level app such as shards shouldn't really need to worry about.
I understand these helpers would be universally applicable and would most likely be useful for other Crystal programs. So perhaps we should move them to stdlib?

[Sija]

I'd suggest to put those (helpers) in a Windows namespace or mark them in other way (prefix, perhaps?) as windows-specific.

[HertzDevil]

Moving things into stdlib (even Crystal::System) could break backward compatibility because previous versions of Crystal won't have the same helpers. In fact we might have inadvertently broken it before, and we should have some assurance that Crystal 1.0.0, or even 0.35.0 as suggested in Shards itself's shard.yml, is able to build Shards.

[straight-shoota]

Windows is not fully supported anyway, so I wouldn't worry too much about it. We can still keep a copy of the code in shards repo to backfill for older Crystal versions. But ultimately, I don't think this should be part of the shards codebase.