[CT-2042] Enable seeds to be handled from stored manifest data

[gshank]

Right now we don't store the content of a seed file, we just store a checksum of the content or just the path if the size of the seed exceeds 1 megabyte. The seed is retrieved later using the absolute path of the file. This is not functional for a world in which files can come from a file diff and we have portable manifests.

We need to decide how to do this for file diffs and portable manifests. How important is the existence of large seeds to our users? It is documented as an anti-pattern, but I'm sure some people are doing it. Do we want to load the content below a certain size? Do some kind of special handling?

[jtcohen6]

My instinct here is that we should start storing raw seed contents up to 1 MB. For any seeds that are larger, we should continue storing only the file path pointing to that seed.

That would be consistent with the behavior we've established for detecting seed modifications in state:modified: comparing a checksum of contents for seeds that are <1 MB; only comparing the file path for seeds that are >1 MB.

The risk is that a project has 100 seeds, each 0.9 MB in size, and we've suddenly bloated the manifest by 90 MB. We could also look into compression... or that could be a problem for another application to solve.

[jtcohen6]

Let's revisit & prioritize as part of broader scoping for file_system work

[ChenyuLInx]

In order to do this we might want to break out the current manifest into several individual pieces first.