allow_overwrite is accepted by DEFINE_multi_* and never consulted

`allow_overwrite=False` is accepted by the `DEFINE_multi_*` functions, stored on the flag, and never read.

```python
flags.DEFINE_string('single', 'x', 'help', allow_overwrite=False)
flags.DEFINE_multi_string('multi', [], 'help', allow_overwrite=False)

FLAGS(['prog', '--single=a', '--single=b'])
# IllegalFlagValueError: flag --single=b: already defined as a

FLAGS(['prog', '--multi=a', '--multi=b'])
# no error; FLAGS.multi == ['a', 'b']

FLAGS['multi'].allow_overwrite # False -- stored, but never consulted
```

`Flag.parse()` enforces it (`_flag.py:192`). `MultiFlag.parse()` overrides the method and the check is not carried over; the string `allow_overwrite` does not appear in its source.

**I do not think the guard should simply be copied down, and that is why this is an issue rather than a PR.** `parse()` is called once per matching token within a single argv pass, so `present` is already nonzero on the second `--multi=` of an ordinary command line. Porting `if self.present and not self.allow_overwrite: raise` would make every `allow_overwrite=False` multi-flag reject its second value in exactly the usage the class exists for.

So the real question is which of these you want:

- reject `allow_overwrite=False` at definition time for multi flags, since it cannot be honoured
- document it as inapplicable there
- distinguish "same parse pass, building a list" from "a genuinely separate override", which nothing in the current design tracks

Reported because a silently ignored keyword is easy to rely on by mistake. Whatever the resolution, a test would help: `flags_test.py` and `_flagvalues_test.py` exercise `allow_overwrite=False` only on string, integer and alias flags.

Measured on CPython 3.13.13.