Custom error for tuple arg when multiple args are expected

A Titular_Hero on stack overflow [reports the following code snippet](https://stackoverflow.com/q/71339444):

```haskell
import Data.List

encode [] = []
encode ls = zip((map head list), (map length list))
where list = group ls
```

This produces the error message:

```
T.hs:3:13: error:
* Couldn't match expected type: [a1]
with actual type: [b0] -> [(a0, b0)]
* Probable cause: `zip' is applied to too few arguments
In the expression: zip ((map head list), (map length list))
In an equation for `encode':
encode ls
= zip ((map head list), (map length list))
where
list = group ls
* Relevant bindings include
encode :: [a] -> [a1] (bound at T.hs:2:1)
|
3 | encode ls = zip((map head list), (map length list))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

T.hs:3:16: error:
* Couldn't match expected type: [a0]
with actual type: ([a], [Int])
* In the first argument of `zip', namely
`((map head list), (map length list))'
In the expression: zip ((map head list), (map length list))
In an equation for `encode':
encode ls
= zip ((map head list), (map length list))
where
list = group ls
* Relevant bindings include
list :: [[a]] (bound at T.hs:4:8)
ls :: [a] (bound at T.hs:3:8)
encode :: [a] -> [a1] (bound at T.hs:2:1)
|
3 | encode ls = zip((map head list), (map length list))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

First of all, it is not ideal that this produces two (rather lengthy) error messages.

But more importantly, I think the error message for this code should mention that arguments should just be passed separately and not in a tuple. Although, a programmer making this mistake is probably not aware of the fact that they are using a tuple, so I would suggest to try to describe it in another way in an improved error message.

The accepted answer by chepner is worded like this:

> You are trying to use C-style syntax to call zip, which is interpreted as zip getting a single tuple as its argument, rather than the two lists you intended.

Perhaps a slight modification/generalization of this could be a good start for an improved error message.

Start by reproducing the Haskell snippet from the issue and inspect how its two type errors are reported. Determine where the compiler could recognize the tuple passed to a multi-argument function; done means producing one concise diagnostic that explains the argument mistake without requiring the two lengthy messages.

Written by the indexing model from the issue text.