[Rule] Too many arguments without default

Nobody has claimed this yet.

I am personally not a fan of the rule `too-many-arguments`. Instead, I want to propose `too-many-arguments-without-default`.

A lot of arguments can make a keyword cumbersome to use. It can also be an indication of too much keyword complexity. However, I don't think having a lot of arguments with defaults is always an issue. For example:

```robotframework
*** Keywords ***
Create user account
[Arguments]
... ${environment}=tst
... ${type}=online
... ${validateAge}=${True}
... ${validateEmail}=${True}
... ${acceptTerms}=${True}
... ${retentionDays}=${14}
```

This is (a modified version of) a keyword we use all the time for user account creation. Note it has more than the default allowed 5 arguments, but all have a default value. The unmodified version has 10 arguments, all with a sensible default value.

In most tests, we use the keyword without arguments. In tests where we need a specific account state, we use the keyword with a few arguments overwritten. I think that with a pattern like this, you can create great keywords with many arguments. These keywords offer great flexibility.

At the same time, I think that the following is a bad pattern and should not be used:

```robotframework
*** Keywords ***
Create user account
[Arguments]
... ${environment}
... ${type}
... ${validateAge}
... ${validateEmail}
... ${acceptTerms}
... ${retentionDays}=${14}
```

There are too many arguments here that you always have to explicitly fill. This makes the keyword hard to use and hard to understand.

There are a few ways we can achieve this:

1. Add the new rule `too-many-arguments-without-default` as a non-default rule.
2. Add a new parameter to the existing rule `too-many-arguments`. This parameter could be called `ignore_optional_arguments`.
3. Make this the new behavior of the existing rule `too-many-arguments`.

If you agree with me, please let me know and I'll open a PR.

Start by reviewing the existing `too-many-arguments` rule and the discussion in this issue. Compare the three proposed approaches, including whether the behavior should be default or opt-in, and confirm the preferred scope with maintainers. Done means the rule behavior and implementation approach are agreed and covered by the project's relevant checks.

Written by the indexing model from the issue text.