text: Title: support (or don't support) freeform parameters with `--extra-vars`
  Body: ### Summary
  
  if you use a string for your `--extra-vars` that doesn't start with `{` or `[` and doesn't contain `=`, this is considered by the `parse_kv` splitter as a "free-form parameter", and gets thrown into a variable `_raw_params`, which is meant to be used by some modules to support a more terse syntax ([source code](https://github.com/ansible/ansible/blob/4a710587ddd043ee729d85ab987c85193f9885c7/lib/ansible/parsing/splitter.py#L88-L91)). If you use multiple such `--extra-vars`, The global `_raw_params` variable stores only the last one.
  ```console
  $ ansible localhost -e foobar -m debug -a 'var=foobar'
  localhost | SUCCESS => {
      "foobar": "VARIABLE IS NOT DEFINED!"
  }
  ```
  
  ```console
  $ ansible localhost -e foobar -m debug -a 'var=_raw_params'
  localhost | SUCCESS => {
      "_raw_params": "foobar"
  }
  ```
  
  ```console
  $ ansible localhost -e foobar -e barfoo -m debug -a 'var=_raw_params'
  localhost | SUCCESS => {
      "_raw_params": "barfoo"
  }
  ```
  
  I think it would be a nice feature if free form `--extra-args` would set the specified variable to `true`. Currently the only way to set a variable to `true` from the command line involves typing out a whole JSON dictionary in a shell argument, avoiding quotation issues.
  
  I think free form `--extra-vars` should at least be an error if it won't be supported. Storing a CLI arg as global `_raw_params` and clobbering CLI args over each other isn't very good behavior.
  
  ### Issue Type
  
  Feature Idea
  
  ### Component Name
  
  splitter
  
  ### Additional Information
  
  At my workplace we do something sort of like `-e run_special_tasks=true`, and then reference that variable using `when: run_special_tasks | default(false) | bool`. This has issues:
  * `to_bool` assumes literally anything is false except for a short list of truey strings and `1`. this means that `2` is false, `"lorem ipsum"` is false, lists are false, dictionaries are false. [source code](https://github.com/ansible/ansible/blob/4a710587ddd043ee729d85ab987c85193f9885c7/lib/ansible/plugins/filter/core.py#L83)
  * we have to remember to never reference the value of this variable without type casting it first. We can also create a second variable that contains the boolean value of the 1st, but then we have to remember never to use the 1st. How can this be enforced? Custom extensions to `ansible-lint`?
  
  Instead, if this was supported, we could do `-e  run_special_tasks`, and reference that variable as `when: run_special_tasks | default(false)`. I think this would be intuitive and elegant.
  
  ### Code of Conduct
  
  - [x] I agree to follow the Ansible Code of Conduct