[Feature Request]: Fix event behaviour to properly handle the case when an exploration is resumed

[seanlip]

Is your feature request related to a problem? Please describe.

Some events are not handling the "resuming an exploration" user flow correctly -- either through not recording enough data or by recording data in a confusing way. In particular:

• resume_exploration_context events don't include an exploration ID or a state name
• hints/solutions that were offered/unlocked before the resumption can be offered/unlocked again after the resumption

Describe the solution you'd like

• [ ] resume_exploration_context events should include an exploration ID
• [ ] There should be a start_card event after each resumption, so that the state name at which the resumption happened can be determined.
• [ ] On resuming, hints/solutions that were offered/unlocked before the resumption should not be re-offered/re-unlocked (i.e. the offer/unlock state should be the same as what it was when the learner left the exploration).

Describe alternatives you've considered N/A

[adhiamboperes]

Suggested fix for task 1 and 2:

Change the type of resume_exploration_context in oppia_logger.proto from LearnerDetailsContext to ExplorationContext, and cascade down this change to EventBundleCreator.kt, EventLogSubject.kt and related tests. We would need to move resume_exploration_context to a new field number and reserve 28 for backward compatibility.