Fix to player component scoreScreenURL handling

[clpetersonucf]

Resolves #1558. This is a high priority issue.

The widget-player component assigns a default value to the scoreScreenURL state object, but if played in an LTI context, the on_play_completed_event returns a score_url value that's appended to the response object of play_logs_save if the score module reports the play is completed.

The problem is that the scoreScreenURL state object is updated independently of the rest of the component's state values that manage the overall player state. As best I can tell, under certain circumstances, the scoreScreenURL is not updated before the playState state value, and the hook responsible for navigating to the score screen fires with the old scoreScreenURL value instead. Because of the nature of the race condition, this is very difficult to test.

This PR:
Defers the queueProcessing flag from being reset to false if the score_url value is present in the response until after the scoreScreenURL is properly updated (via another useEffect hook). The queueProcessing flag must be false before the playState is updated to end, which is one of the trigger conditions for navigating to the score screen

Replaces the scoreScreenURL state object with a useRef hook, which is updated immediately and maintained across renders.

[cayb0rg]

Reproduced the issue using setTimeout(() => { setScoreScreenURL(result.score_url) }, 5000). This seems to have fixed it. Only potential, and similar, issue I see being is setQueueProcessing(true) taking too long, and either nothing happens or duplicate play_log_save calls are made, but as I couldn't actually cause this to happen without using setTimeout, I don't think it's something to worry about.

[clpetersonucf]

In my rush to engineer this fix yesterday, I completely overlooked useRef as an alternative to maintaining scoreScreenURL in state. Reworked the fix to leverage useRef instead, which should be much simpler and reduces the odds of additional race conditions.

[clpetersonucf]

Closing this and re-opening as a more comprehensive set of fixes associated with the passback bug.