text: Title: Support variables in format `$var` in addition to `${var}`
  Body: Curly braces required by Robot's variable syntax can be considered somewhat distracting and even ugly. Depending on the keyboard layout, writing them can also require annoying finger acrobatics. It would thus be convenient if it would be possible to use `$var` instead of `${var}` and also `@list`, `&dict` and `%env` instead of `@{list}`, `&{dict}` and `%{env}`. For example, all these could be supported:
  
  ```
  *** Variables ***
  $VARIABLE        value
  
  *** Test Cases ***
  Example
      Log    $VARIABLE
      $var =    Keyword
      FOR    $item    IN    @stuff
          Log    $item
      END
  ```
  
  In all the above cases the `$var` syntax is used on its own and that would work fine. This syntax wouldn't work too well when embedded to a string, though. For example, if you have variables `$name` and `$named`, string `Hello, $name!` could be parsed like `Hello, ${name}!`, but `abc$named` could be either `abc${name}d` or `abc${named}`. We could require using the `${var}` syntax in cases where `$var` is ambiguous, that's how [shell scripts](https://learn-bash.org/variables.html) work, but I believe it's better to require it always when variables are embedded. That makes the syntax more consistent and this approach is also considerably easier to implement. We can, however, look at this again later if the `$var` syntax is universally considered better and using it always (when possible) is considered important.
  
  Supporting the `$var` syntax would be a backwards incompatible change, but if we support it only when variables are used on their own, it shouldn't be that bad. It would mean that all arguments starting with `$`, `@`, `&` and `%` would need to be escaped like `\$not_var`. We already require this with `#` (which otherwise starts a comment) so there's precedence for such syntax. Nevertheless, this would break lot of tests/tasks and the change can be made only in a major version. It would also be a good idea to deprecate using arguments starting with these characters already earlier. If this enhancement is considered important, it could be added in RF 7.0 and deprecation added in RF 6.2 or possibly already in RF 6.1.
  
  Although the basic syntax would be simple, there are some design decision to be made:
  
  1. Should we limit variable base name to only alpha numeric characters and underscore? In other words, should something like `$! als lkjas` be considered a variable with base name `! als lkjat` or should the whole thing be considered a literal string? Being more strict with the variable name would mean there's less need for escaping, but then these variables would work inconsistently compared to "normal" variables. It would also mean that some built-in variables like `${/}` couldn't be used like `$/`. I got a feeling that it's better if we don't limit the name. 
  2. Should this syntax support item access like `$list[0]` and `$dict[key][nested]`? I believe it should.
  3. Should this syntax support "extended variable syntax" like `$var.upper()` and `$SPACE * 10`? I don't have too strong opinion on this, but I guess it would be better to support it. Needing to use `${var.upper()}` in this case would be a bit strange and inconsistent.
  
  I'll add this issue tentatively to RF 7.0 scope, but we still need to make a bit more official decision about it. If we decide to include it, then another issue should be submitted about deprecating arguments starting with `$` and other such variable meta characters.