Add support for standalone executables

[nex3]

dart2native supports generating fully standalone executables, and we should ideally support this as well for standalone compilation. There are some complications, though: on OS X and Windows, standalone executables need to be signed or they'll produce scary and annoying warnings when they're run. This requires that users purchase a trusted certificate for each OS and run a command to sign the generated executables with those certificates. See details for OS X and Windows.

I think the best way to handle this would be to have pkg.standaloneWindowsCert and pkg.standaloneMacOSCert fields and, if those fields are set, generate full standalone executables and sign them. I don't think it's especially useful to generate unsigned executables; they won't be much faster than native snapshots, and the generated warnings will be very frustrating.

Note that for Linux, this is much easier, since code signing isn't required. Given that all three supported operating systems are substantially different here, I'm going to split this up into three tasks:

• Linux
• Windows
• Mac OS

[loic-peron-inetum-public]

It seems that the dart SDK binaries are not signed either, so I do not see any benefit in avoiding a standalone executable. To the contrary, it blocks the integration to the winget catalog (https://github.com/microsoft/winget-pkgs/blob/master/.github/ISSUE_TEMPLATE/package_request.yml)

My attempt to have FVM added to the winget catalog has been rejected just for that reason (microsoft/winget-pkgs#272766)

I would like some guidance to implement this feature, behind a flag if necessary.

[loic-peron-inetum-public]

Followup to #135 (comment) @nex3

Although Dart can compile to a standalone EXE, there's a major barrier to making this usable: those EXEs must be code-signed in order to run without a warning, and setting up a code-signing pipeline is substantially more difficult than just uploading to a package repository. We ship a multi-file bundle because the Dart EXE is already code-signed and so can run without any issue.

That is not entirely true, otherwise no unsigned EXE could be run on windows, such as those produced by all native development tools (C/C++, golang, rust, dart, etc). In fact, current dart EXE as used by the Flutter SDK, or bundled with FVM, is not signed (checked just right now) and runs perfectly.

I would also point that CLI tools, deployed on GitHub and Chocolatey, target advanced Windows users like developers. These users (like my development team) already run unsigned EXE. I would rather deploy our tools (FVM in my current case) using winget like our other tools (Visual Studio comes to mind).

[nex3]

I didn't say that unsigned EXEs couldn't be run at all, I said they couldn't be run without a warning. How disruptive or confusing that warning is will vary from user to user; for Sass, with a relatively design-focused audience, it's a real barrier. I'd be okay adding an off-by-default option to support generating an unsigned executable on Windows, but that's as far as I'd go.