fix(SFT-2740): improved script loading for captchas + more spam reason message info

[seandelaney]

This still doesn't fix the issue we had on SFT-2740. Its more to help debug and prevent real submissions not making it to the finish line.

Servers side changes:

• If missing token then we always show an error, never silently flag submission as spam. Also a sure sign that something is blocking the token request to API.
• If the token is present but rejected by API, then respect failure behaviour setting - send to spam or display an error.
• The form handle is now included in spam reason messaging - basically if a customer sees a spam submission for contact but the reason says newsletter, there's a clear sign the captcha token from one form is being validated against another form - clean sign we have a bug somewhere else.
• I updated captcha error strings to be more descriptive. Useful when a user has multiple captchas enabled on the same form and they are fighting each other.

Client side changes:

• Captcha script loader now resolves immediately if the same script is already loaded in the DOM.Previously the promise was never resolved. We left it outside the rain.
• Removed submit button from lazy-load triggers list. This fixes a race condition I managed to replicate when testing. I was loading the form with autofill extension and clicking submit button.
• Added captcha JS polling. So whether the user fills out form fields and/or clicks submit, if the user is on a very slow connection, we now wait for the captcha scripts to load before submitting the form. Times out after 8 seconds and lets server side validation checks handle it. Basically if the JS still hasn't loaded after 8 seconds, its a sure sign its blocked by firewall etc.

[gustavs-gutmanis]

Looks great!
I would probably move the waitForToken function into a common one used by all of the captchas, since only the selector changes.