text: Title: Simpler syntax to create lists, dicts, and other collections as arguments to keywords
  Body: Robot's automatic argument conversion (#2890) makes it possible to have a keywords like
  ```python
  def accept_list(arg: list):
      ...
  
  def accept_dict(arg: dict):
      ...
  ```
  and call them so that argument are Python literals
  ```
  Accept List    ['list', 'items', 'here']
  Accept Dict    {'key': 'value', 'another': 'item'}
  ```
  
  This is pretty convenient, but needing to use Python syntax is a bit ugly in general and especially annoying when using embedded arguments that are supposed to enhance readability:
  ```
  Select animals ['cat', 'dog'] from list
  ```
  
  I propose we enhance argument conversion so that we support also the following syntax:
  ```
  Accept List    list, items, here
  Accept Dict    key=value, another=item
  ```
  
  The high level semantics would be as follows:
  
  - Separator between items is a comma _and_ a space. This allows using commas in values like `first, second,with,commas, third`. Having a comma followed by a space in the value wouldn't be possible.
  - We could allow using a semicolon and a space as an alternative separator. In that case we'd use the separator that's encountered first. This would allow usages like `first; second, with, commas followed by spaces; third`.
  - With dictionaries the separator between key and value is `=`. This is the syntax we use also when creating `&{dict}` variables.
  - Values are considered strings by default. This can be changed by using generics (#4433) and `TypedDict` (#4477).
  - Because this would be handled by type convertors, variables would have been resolved already earlier. That means that something like `${1}, ${2}` wouldn't create a list of integers. See the above point for alternatives.
  - Also escapes are handled before type conversion. That makes it impossible to use something like `first, second\,with\,commas` for escaping commas in values.
  
  This enhancement would ease using collections a lot especially if #4433 and #4477 are implemented. If we agree above semantics are fine, implementation would also be pretty easy. I thus add this to RF 5.1 scope even though the release is already late.