Fix Sudden Crash from Exitting Main Loop

[InnocentusLime]

Synopsis

Issue #681 is still valid for the latest master version of macroquad. This PR fixes the crash from this issue. The main reason it happens in the first place is as follows. Closes #681

Macroquad apps are generally structured in the following way:

#[macroquad::main("Your title")]
async fn main() {
  loop {
   draw_circle(screen_width() - 30.0, screen_height() - 30.0, 15.0, YELLOW);
   next_frame().await;
  }
}

When you exit main after draw_circle and alike, but before next_frame() -- the context of macroquad is left in a sort of bad state. It contains a lot drawcalls, but all the resources it points to are dead, because they were locals in main(). The event loop still calls end_frame, which causes quad_gl.rs to access a bunch of dangling references.

This implicit "zones" in user's code, where they can or can not exit

#[macroquad::main("Your title")]
async fn main() {
  loop {
   /* Can exit here :D */
   draw_circle(screen_width() - 30.0, screen_height() - 30.0, 15.0, YELLOW);
   /* Can't exit here or else we will have dangling refs :( */
   next_frame().await;
  /* Can exit here. Draw calls have been cleaned up :D */
  }
}

The Fix

The fix this PR proposes is to force-reset the quad_gl stuff after main() exits.

Alternatives

• Store strong references in DrawCall
  • Pros: No extra code
  • Cons: The resource lifetime becomes less controlled by the user, because it now relies on when quad_gl.rs releases the strong referneces
• Do not call end_frame when main exits
  • Pros: I guess it will keep lib.rs a bit cleaner?
  • Cons: The event loop will need stuff to detect that main has exited
• Do nothing! Maybe just add a FAQ about this issue
  • Pros: Do nothing!
  • Cons: This behaviour is confusing and complex enough to make new people report it as a bug