Reconsider the choice of adding a newline after multi-line option definitions

[janluke]

First, thanks for your work.

I ask you to reconsider the feature introduced with PR #1081.

1. Adding a newline only to some options feels inconsistent and leads to a weird-looking "non-uniform" help strings. It's even worse when you use an extension that adds new help sections (e.g. Cloup for option groups), since some sections are not clearly demarked or too much demarked. It looks like a complete mess.

2. I'm pretty sure it's non-standard. Why should it be the default?

As a consequence, it feels like a bug. I did mistake it for a bug. Another developer reported it as a bug (issue #1559). The few people I asked don't like it and consider it a problem worth the effort of writing additional code to get rid of it. Most people in the original issue (#1075) are for an all-or-nothing behavior and described the current behviour as inconsistent as well.

Here's some alternative proposals.

1. Remove the feature.
2. Make it possible but non-default. Two solutions here:
   1. Add a parameter to HelpFormatter. It can be made as simple as a boolean or as complex as a "list item separation strategy". A user can pass a custom factory function as Context.formatter_class (which probably could be called formatter_factory).
   2. Refactor HelpFormatter to make it easy for people to override without copying, pasting and modiyfing the current code of HelpFormatter.write_dl.

Thank you again.

[davidism]

Refactor HelpFormatter to make it easy for people to override without copying, pasting and modiyfing the current code of HelpFormatter.write_dl.

Yes, as stated in #1075 (comment), making the formatting overridable is what I want.

[davidism]

That said, I'm not sure why I accepted it so quickly in the first place, but that was 3 years ago. Feel free to revert it.