User feedback improvements

[plocket]

Some slightly chaotic notes from a run through with a user:

• When selecting files to create tests for, user selected both the interview file and a file the interview file depends on. When they re-read the sentences upon instruction, they understood, but they would have carried on if allowed. How do we emphasize that more? Bold? Caps? A term with a short explanation of why? [handled by Closes #209 Clarify which type of files user should be selecting #210]
• Emphasize that they shouldn't set the SERVER_URL secret to their production server. In conjunction with that, the testing account also has to be on the dev server, not production.
• Instead of just suggesting to set up a dummy testing account (for the docassemble server API key), tell people to do it.
• This might be their second time going through, though, so "If you don't already have a test account...".
• Also, the testing account should have a valid email so they can recover the password if needed, which they can do now if they've forgotten the password.
• Also, they can just make a new testing account if they're really stuck.
• Maybe add to Suffolk documentation explaining about a testing account and the pros and cons. e.g. if you just use an existing account, that person may run into situations where Projects look like they're randomly appearing and disappearing from their Projects menu.
• A testing account "on your server" -> on your docassemble server
• When we tell them to create the API key, do we say use "no authentication"? That flashed by too fast.
• Switch to using new token interface. That is, update from classic. Include in instructions to not use classic/to use the new kind. Wish GitHub hadn't made this so confusing. Either that (or in the meantime), or give directions to use 'classic'.
• Maybe bold the name of the type of token permission to give. Maybe add "Attention:" at the beginning. User didn't went through once to make tests, then didn't notice the different token permissions when they went through to set secrets.
• Token: Add "This will be temporary"? "Just the setup uses this, the tests won't use it"?
• Edit: Explain why they'd want to override secrets (in a term or something?)