Refactor: {{action}} helper usage, the sequel

[DrumsnChocolate]

DO NOT MERGE BEFORE #635 IS MERGED

bases on #635
ref #899
may require a third PR after this

How to review this:

• have a look at some of the changes, to get an idea of what this PR is doing.
• manually test all pages that have been affected by this PR, and see if the buttons on those pages work as expected.

New prevent-default helper

This PR also introduces a new template helper: prevent-default. It is used to wrap the action we assign to be executed when an event takes place. Specifically, it adds a call to event.preventDefault(). Why would we do this in a helper? Well:

1. because we don't want to pollute the js files with e.preventDefault(); calls.
2. the decision of whether or not to call preventDefault should take place in the template, because that's where it is easiest to determine.

To elaborate on point two, when we have the following action:

@action
someAction() {
    someLogic();
}

Then a template with

<form {{on 'submit' someAction}}></form>

requires a call to e.preventDefault():

@action
someAction(event) {
    event.preventDefault();
    someLogic();
}

otherwise the page is reloaded automatically (because that's what a submit event on a form does, apparently.) Now, suppose instead the template contains

<ComponentForDoingSomething @doThis={{someAction}}></ComponentForDoingSomething>

then we don't need a e.preventDefault() call... See how that's confusing? Sidenote: in reality the underlying ComponentForDoingSomething generally still performs a call to e.preventDefault, but that's none of our business, since principles like dependency inversion dictate that we do not concern ourselves with the implementation details of a child component, but only with the parts we can 'see' of that child component.

Now let's make the point even better: if we have a problematic template that contains both of these types of usages:

<form {{on 'submit' someAction}}></form>
<ComponentForDoingSomething @doThis={{someAction}}></ComponentForDoingSomething>

then what do we do? We need to call e.preventDefault() for one element in the template, but not for the other. But that's easily solved with the new helper:

<form {{on 'submit' (prevent-default someAction)}}></form>
<ComponentForDoingSomething @doThis={{someAction}}></ComponentForDoingSomething>

[codecov]

Codecov Report

Attention: Patch coverage is 4.87805% with 39 lines in your changes missing coverage. Please review.

Project coverage is 13.32%. Comparing base (26735a6) to head (9257be7).

Files with missing lines	Patch %	Lines
app/components/form/response/response-form.js	7.14%	13 Missing ⚠️
app/components/form/response/response-card.js	0.00%	9 Missing ⚠️
app/components/form/responses-table-card.js	0.00%	8 Missing ⚠️
app/components/form/form-form.js	16.66%	5 Missing ⚠️
app/helpers/prevent-default.js	0.00%	3 Missing ⚠️
app/components/form/response/open-question.js	0.00%	1 Missing ⚠️

Additional details and impacted files

@@                       Coverage Diff                        @@
##           refactor/action_helper_usage     #896      +/-   ##
================================================================
- Coverage                         13.63%   13.32%   -0.31%     
================================================================
  Files                               450      451       +1     
  Lines                              3081     3076       -5     
================================================================
- Hits                                420      410      -10     
- Misses                             2661     2666       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[DrumsnChocolate]

I initially began rewriting components to glimmer when I encountered them, but that's quite a lot of work and not strictly related to the task this PR is really meant for. I've found it more efficient to just refactor all action helpers and leave other non-octane things as they are for now. We can tackle them in other PRs.

I've also not tested that every action occurrence I've refactored in in this PR still functions properly. Not yet at least. I did test that for #635 , but I figured it's more efficient to first rewrite, and then go through all the corresponding pages and test their functioning.

[DrumsnChocolate]

also fixes some styling in the print-enrolled component.
before:

after:

not perfect but quick win