feat: remove direct drive arrows

[razvan-pro]

Description

• Removed the direct_drive attribute from the Level model and all relations to it from the frontend. This will remove the direct drive arrows mentioned in Remove direct drive arrows #1662.
• Replaced the "Go" button references in the level descriptions with the "Play" button.
• Renamed CSS class .direct_drive_button to .zoom_pan_button as it's only used for the zoom buttons now.
• Removed _setupDirectDriveListeners JS functions as it's no longer used when the direct drive buttons are removed.
• Removed the "Go" button SVG. Note that the other assets are still in use by the code blocks, so they couldn't be removed.

How Has This Been Tested?

• Ran locally and checked the buttons are not there anymore.
• Went through the levels 1-18 descriptions to check for references to the direct drive buttons.

Screenshots

Direct drive buttons removed

Go button replaced with Play icon and text in level description

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have linked this PR to a ZenHub Issue.

---

This change is 

[razvan-pro]

@faucomte97 Do I really need to make my email address public on a GitHub page to sign the agreement? 😬 I like the idea of validating this automatically, but I'm sure there is a better way that doesn't involve making personal information publicly available. E.g. adding the private GitHub email address should work technically; storing the usernames and email addresses in a database and making an API endpoint to check the GitHub username rather than the email address would also work.

[faucomte97]

@razvan-pro No worries about that atm, we are about to put in place a completely new system which won't require contributors to publicise their email address. We're essentially building a "contributor service" which will allow users to login via Github, and agree to the contributor agreement directly on there without needing to a) edit the contributor agreement file and b) respond to an email - so it'll be a lot smoother 🙂
You can check the code for it here 😄

I can let you know once we've deployed this so you don't need to follow the old process

Edit: And essentially yes, the contributor service we've built does what you've suggested 😃

[razvan-pro]

@faucomte97 That's an excellent solution, thanks for this! I had something like this in mind, but I thought it might be too high effort to suggest - it's great to see it's already in progress! 😊

Yes please, let me know when it's deployed. 🙏

Do you think it will be ready in time to merge this PR by the end of October for the hacktoberfest? 😁

[faucomte97]

@razvan-pro thanks 😃 Unfortunately I don't think we'll have the service up and running by the end of the month...

We were thinking, would you be happy to use a "temporary" email address for this purpose? Like a new gmail address for example that you'd use only for contributing - you could have that be public and the we could then verify it, until we release the new service.

What this means though is that you'd need to close this PR and make a new one authored by that new email address, but hopefully it shouldn't take too long 😬

Let us know what you think

[razvan-pro]

@faucomte97 I was about to do that, but it looks like if I remove the email address later from my account, the commits won't be associated with my account anymore 😬 so I'd have to keep the temporary email address. I think I'll wait for the new service (it's fine if it's outside hacktoberfest). I assume adding the private github email to the list won't work, right? From what I saw, there's an action that sends the agreement automatically, so I wouldn't want to break things 🙂

[faucomte97]

Reviewed 10 of 10 files at r1, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @razvan-pro)