Should "garbage at end of line" be a hard error?

This was raised by email by @KaraZajac. Right now if 'garbage at end of line' is detected, the previous bits have been succesfully parser and accepted. This is e.g. to make sure incorrect line-endings don't cause full lock-outs.

In the case of other parse-errors (or bugs in the parser), it is conceivable that this causes incomplete config lines to be accepted (albeit with a warning). We could also add code that ensures that, in the case of a "garbage at end of line" error, the part before it is rejected also. This would in effect add some extra defense in depth.

We could also do this in an intelligent manner rather than all-or-nothing; in a similar vein, we ignore NOINTERCEPT as a keyword (sudo-rs emits a warning for it, but the rest of the configuration rule will continue to be understood), but if we encounter INTERCEPT that means we reject the whole rule since we don't implement subcommand interception.

Start by tracing the Rust parser path that detects "garbage at end of line" and compare it with handling for NOINTERCEPT and INTERCEPT. Determine whether the intended behavior is to reject the parsed prefix, selectively reject rules, or preserve the warning behavior; done should include a decided policy and coverage for the relevant parse cases.