Revert "Merge upstream changes that have occurred since the fork (#59)"

[nagisa]

This reverts commit 0402edd.

The final result in the main branch did not retain the merge commit, so trying to merge the upstream/main again now produces significant conflicts even though they should not be present.

[nagisa]

cc @Ekleog-NEAR this is an interesting case where merge queue setup fails spectacularly.

So originally I PRd a merge commit, pulling in bytecodealliance/wasmtime:main changes since the last fork. Then the merge queue "squashed" and "normalized" everything which caused this merge commit to instead become this humongous +100k,-100k commit. And now when I try merging again, it fails with a crapton of conflicts, because the only common base commit git sees with the bytecodealliance/wasmtime:main is the original base, and this +100k,-100k commit introduces a crapload of conflicts :D

[Ekleog-NEAR]

@nagisa TBH I never understood why we squash-and-merge. This is already temporarily disabled on nearcore (because of the TOCTOU issue with reviews, see the bp issue thread on zulip), and it uses a merge commit there. I guess switching to merge commit everywhere might make sense for the reason you mention :)

[nagisa]

TBH I never understood why we squash-and-merge.

Linear history in the main branch is pretty darn nice.

[Ekleog-NEAR]

Linear history in the main branch is pretty darn nice.

I mean there’s git log --first-parent, git bisect --first-parent, and AFAICT basically all git commands have a way to ignore the branches and treat the merges as though they were squash-merges