text: Title: Make `FOR IN ZIP` loop behavior if lists have different lengths configurable
  Body: Robot `FOR IN ZIP` loop behaves like Python's  [zip](https://docs.python.org/3/library/functions.html#zip) so that if lists lengths aren't the same, items from the longest one are ignored. For example, the following loop would be executed only twice:
  
  ```robotframework
  *** Variables ***
  @{ANIMALS}    dog      cat    horse    cow    elephant
  @{ELÄIMET}    koira    kissa
  
  *** Test Cases ***
  Example
      FOR    ${en}    ${fi}    IN ZIP    ${ANIMALS}    ${ELÄIMET}
          Log    ${en} is ${fi} in Finnish
      END
  ```
  
  This behavior can cause problems when iterating over items received from the automated system. For example, the following test would pass regardless how many things `Get something` returns as long as the returned items match the expected values. The example even succeeds if `Get something` nothing.
  
  ```robotframework
  *** Test Cases ***
  Example
      Validate something    expected 1    expected 2    expected 3
  
  *** Keywords ****
  Validate something
      [Arguments]    @{expected}
      @{actual} =    Get something
      FOR    ${act}    ${exp}    IN ZIP    ${actual}    ${expected}
          Validate one thing    ${act}    ${exp}
      END
  ```
  
  To avoid the above example failing if `Get something` returns more or less values than expected, a separate check needs to be added. Because there's no ready-made keyword for checking are list lengths equal (`Lists should be equal` keyword doesn't work here), the validation needs to use something bit more complicated like this:
  ```
      Should be equal    ${{len($actual)}}    ${{len($expected)}}
  ```
  For a real life example see [this example](https://github.com/robotframework/robotframework/blob/f7ee913622e60c0cf630e1580c2bb58c57100187/atest/robot/running/if/invalid_if.robot#L119) from out acceptance tests. Tests also contain various `FOR IN ZIP` usages where this particular issue could cause problems.
  
  This same underlying issues has caused problems with Python's `zip` as well. Starting from Python 3.10 (see [PEP 619](https://peps.python.org/pep-0618/) `zip` has new `strict` parameter that can be used like `zip(actual, expected, strict=True)`. It causes a `ValueError` to be raised if iterated lists have different lengths. Related to this, Python also has separate [itertools.zip_longest](https://docs.python.org/3/library/itertools.html#itertools.zip_longest) that goes through all items in all lists so that if certain list has less value than others, value specified with the `fillvalue` argument is used instead.
  
  My proposal is that we add new `mode` configuration option to `FOR IN ZIP` loops. The motivation is that we could have three values `shortest`, `strict` and `longest` emulating Python's behavior with `zip(...)`, `zip(..., strict=True=`), and `zip_longest(...)`, respectively. This was also [considered with Python](https://peps.python.org/pep-0618/#add-several-modes-to-switch-between), but they decided to go with a Boolean option `strict` partly because they already have a separate `zip_longest`.
  
  Another reason `mode` wasn't used with Python is that to properly support the `longest` case, it would require adding `fillvalue` that doesn't make sense with other modes. That's a valid concern in our case as well, but I don't consider it too big a problem. We don't at the moment support the `longest` case at all, so this would instead be a nice enhancement and a lot better syntax than separate `FOR IN ZIP LONGEST` would be.