[WIP] Implement stack_snapshot.vendored_packages

[mboes]

This feature allows overriding packages in the snapshot with targets
defined manually. Useful when the source distribution needs to be
patched, or when the BUILD file needs to be customized.

Closes #902.

[aherrmann]

Looks great, might deserve a test-case for vendored_packages.

Useful [...] when the BUILD file needs to be customized

Yes, I agree that this covers that use-case very well.

Useful when the source distribution needs to be patched [...]

I'm not sure this is equivalent to Hazel's patches feature. With Hazel we get to do the following:

    hazel_repositories(
        packages = hazel_extra_packages(
            extra_pkgs = {
                "network": {
                    "version": "2.8.0.0",
                    "sha256": "c8905268b7e3b4cf624a40245bf11b35274a6dd836a5d4d531b5760075645303",
                    "patches": ["@ai_formation_hazel//third_party/haskell:network.patch"],
                },
            },
        ),
        ...
    )

I.e. here we customize the version of network and also apply a patch to its source distribution, but we don't have to write the boilerplate for defining the actual target.

As I understand this patch, we'd have to do something like this

http_archive(
    name = "network",
    urls = ...,
    patches = ...,
    ...
    build_file_content = """
        haskell_cabal_library(
            name = "network",
            deps = ...,
            ...
        ),
    """,
)

stack_snapshot(
    ...
    vendored_packages = { "network": "@network//:network" },
)

I.e. we have to write the BUILD file ourselves, and in particular we have to list the dependencies for network ourselves.

[aherrmann]

This doesn't seem to be covered by the test-suite.

[mboes]

I.e. we have to write the BUILD file ourselves, and in particular we have to list the dependencies for network ourselves.

Yes, this is correct.

[mboes]

I'm parking this PR as WIP for now. The reason is, while the change is fairly lightweight, it's not super convenient to test, but much more importantly, the work is a little ahead of our actual use cases at this point, especially given that I'd expect many use cases to be covered by Stack custom snapshots instead. We should merge this once downstream starts feeling the pinch of not having this feature.