Does it make sense to add these checks in the case of OOM? Should we "fix" these boundary cases? Or should we just expose them to expose the game code error?

^These questions bother me, but I'm willing to give it a try, so if the changes don't fit please feel free to discuss.

These fixes come from analyzing the OOM crash stack, enhancing some of the checks.
These changed stack contents in cases where an error had already occurred.

RegardingData.Set(), it is envisioned that in the OOM case, fLength retains a non-zero value even if fStorage is empty. It is good practice to perform a Data.Get() check before using it.

Of course, there's also an Android build.gradle.kts issue where switching coronaSrcDir causes the previous project's resource.car content to be incorrectly retained as the gradle script uses the CoronaBuilder car command to do the append action.

This time I modified the file header, replaced Corona with Solar2D and added declarations.

Thanks.