Detect blanks with exercise.blanks opt, and add parse checking

[rossellhayes]

This PR modifies evaluate_exercise() to check whether submitted code contains blanks and whether submitted code cannot be parsed.

If submitted code is unparsable, the R error message is rendered along with a message copied from gradethis explaining that the code could not be parsed and hinting at common causes of this problem.

One special case of unparsability is code that contains blanks. Often, tutorial authors will include blanks in their prompts or hints for students to fill in with valid code, e.g. ___(___, na.rm = TRUE). If submitted code contains blanks, evaluation proceeds as normal, but any feedback is replaced by a message explaining that the submitted code contains blanks and showing what blanks in the exercise look like. This applies even if the code containing blanks is parsable, e.g. if the blank is within a character string. To achieve this, the function return_if_exercise_result() is added within evaluate_exercise(). Each existing check (result check, code check, and error check) is wrapped within that function. This function initiates an early return if a result is signalled, but replaces the feedback with feedback about blanks if blanks are present in the user's code.

By default, any string of three or more underscores is considered to be a blank. This is the most common pattern in existing tutorials. But this definition can be changed with the exercise.blanks chunk option, which accepts a regex pattern to detect as blanks. For example, using {r exercise-check, exercise.blanks = "\\.{3,}"} as a chunk header would detect series of three or more dots as blanks.

Both unparsable and blanks messages are implemented with i18next keys, allowing them to be translated into the same language as the rest of the learnr interface. Instead of producing raw text when encountering unparsable code or code containing blanks, R generates a span tag with data-i18n attributes that are replaced with the correct localized text by the i18next JavaScript library on render. This PR will necessitate adding translations for blank, blank_plural, exercisecontainsblank, pleasereplaceblank, unparsable, and, and or.

[gadenbuie]

This looks great, thank you!

One design question: In gradethis we give users an (undocumented) option as a way to turn this off or modify how unparseable code is handled. Should we also do that in learnr? Perhaps an option analogous to exercise.error.check.code, e.g. exercise.error.parse.check. (There may already be a better option in use in learnr.)

[rossellhayes]

Are you thinking an exercise.parse.error.check would be implemented with global options() or with chunk options? I've implemented it as a chunk option for now.

[gadenbuie]

1. Always run parse checker on submitted code before any evaluation
2. Follow the pattern of the error-check exercise checker
   • Use the exercise.checker function
   • Use the code from *-parse-check chunk as the check_code for that function
   • Or fall back to the global option exercise.parse.check.code
3. If parse failure, return the parse error message with additional friendly feedback

[rossellhayes]

Running into a few test failures on old releases because the new code uses isFALSE(), which wasn't available on R < 3.5.
I could:

1. use backports,
2. include isFALSE() as an internal function, or
3. refactor.

For now I've included it as an internal function in utils.R.

[rossellhayes]

Here's the current state of the checking:

1. Evaluate the global setup chunk.
2. Blank checking can be specified with exercise.blank.check.code. If it's FALSE, no blank checking is performed. If it's NULL, the default exercise_blank_checker() is called. Otherwise, it can be a function.
3. The default blank check is an exercise.checker that marks the exercise incorrect and tells the user how many blanks are still in their code. It detects both parsable (e.g. in strings) and unparsable blanks.
4. Blanks are specified with a regex in the exercise.blanks option. This defaults to "_{3,}".
5. If there are no blanks, move to parse checking.
6. If the exercise engine is not R, skip parse checking.
7. Parse checking can be specified with exercise.blank.check.code, using the same process as step 2.
8. The default parse check is an exercise.checker that marks the exercise as incorrect and an error if the user code cannot be parsed. It gives the same message as gradethis (you may have missed a blank, comma, end parenthesis, etc).
9. If the code parses, then the existing process begins: creating the exercise directory, code checking, etc.

[rossellhayes]

These changes look good to me!