Revert SHA256 field migration

[sophiewigmore]

Summary

In #123 the new checksum and source-checksum fields were introduced, converting all references to sha256 and source_sha256 fields (which are marked as deprecated in packit) into checksums. The problem with that change is that it is a breaking change, and any users of jam functionality would have sha256 fields converted to checksums. Jam shouldn't have opinions on what fields are allowed/not allowed, but should support all possible options.

This PR removes the migrations, and so that sha256 fields are not converted into checksums, and the changes are not breaking.

Test fixtures have been updated to use a mix of both the new checksum fields, as well as showing that sha256 can still be used.

Use Cases

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[sophiewigmore]

This change means that automated buildpack.toml updates using jam will not update the sha256 and source_sha256 fields. Instead, buildpack.toml fields should be manually migrated to use the checksum and source-checksum fields.

[sophiewigmore]

a test case like this with both checksum and sha256 fields is meant to show that when a version isn't added or deleted, it's un-modifed. As in, jam isn't going to modify the sha256 field on any version that isn't being added.

[sophiewigmore]

looks good to me