refactor: put best practice of string option to enum as restrictive validation example instead

Author: david-roper

docs/en/5-reference/5.0-form-instrument.md

@@ -56,6 +56,7 @@ Always consider using \`group\`ing to structure sections
    - Please familiarize yourself with the possible validation rules here
    - Be careful to write the most restrictive validation schema possible
      - Example: likert-scale data should be .int()
+     - Example: A select from multiple string options question should be .enum(['option1','option2', ...]) instead of .string()
      - Remember the API data-entry is independent of the form, so the validation schema must properly restrict API entry as well
 5. Please make sure to format your code whenever possible, as this can prevent annoying issues with missing brackets. In the playground, you can do this with (Alt + F)
 6. If you find yourself repeating code frequently, consider extracting the logic into shared variables. The guiding principle of this should be to maximize readability.
@@ -67,7 +68,6 @@ Always consider using \`group\`ing to structure sections
 8. Use [the playground](https://playground.opendatacapture.org/) to create instruments
    - It is updated regularly to use the latest runtime
    - It is setup with formatting, linting, and type checking by default
-9. Whenever a form field of kind 'string', and of variant 'select' is used, it is much better to have its schema be of type enum containing the possible options instead of type string ( i.e. z.enum(['string1', 'string2', ...]) instead of z.string() ).
 
 ### Example