`snack-runtime` loading time regression on Hermes engine

### Summary

Hey Expo Team 👋,

I'm working with the Draftbit team and we have realized that our live preview app (our wrapper around `snack-runtime`) for Expo 48 is drastically slower than our version for Expo 47. After some investigating, we discovered that the culprit was that the new default for the javascript engine is now Hermes instead of JavascriptCore. Hermes shows an extreme degradation in the speed of loading and transpiling a snack's files and rendering the final output. Hermes is ~2x slower than JSC. As an example with a somewhat large app, Hermes loads in 3.3 minutes while JSC loads in 1.3 minutes. As the app gets larger, the performance difference also gets larger.

Here are some logs for a large app from `snack-runtime` with profiling enabled for Hermes and JSC. Notice how transpiling of each file is drastically slower, and the final time it took to complete.

[48 hermes.txt](https://github.com/expo/snack/files/12915038/48.hermes.txt)

[48 jsc.txt](https://github.com/expo/snack/files/12915039/48.jsc.txt)

For now, we're manually configuring our app to use JSC. I'm not sure if this is a bug on your end or maybe that Hermes is just not well suited for a use case where code is transpiled at runtime.

Thanks for taking the time to read this, let me know if you need any more details.

### What platform(s) does this occur on?

Android, iOS

### SDK Version

48

### Reproducible demo or steps to reproduce from a blank project

Load any project using the `snack-runtime` on the Hermes engine vs on the JSC engine to see the difference in loading times.