Adjusting help message

[murchu27]

NOTE: Originally had #4812 open to merge these changes, but checks were failing in weird ways. @calebcartwright suggested rebasing my branch onto master, but I decided to just delete my fork and start again, and make the changes again on a new feature branch (remove-nightly-help-from-stable). I then merged into the master branch on my fork, and the checks passed there, so hopefully they'll be fine here.

---

On stable, running with --help|-h shows information about file-lines
which is a nightly-only option. This commit removes all mention of
file-lines from the help message on stable.

There is room for improvement here; perhaps a new struct called, e.g.,
StableOptions could be added to complement the existing
GetOptsOptions struct. StableOptions could have a field for each
field in GetOptsOptions, with each field's value being a bool that
specifies whether or not the option exists on stable. Or is this adding
too much complexity?

[murchu27]

Fixes #4798

[calebcartwright]

There is room for improvement here; perhaps a new struct called, e.g.,
StableOptions could be added to complement the existing
GetOptsOptions struct. StableOptions could have a field for each
field in GetOptsOptions, with each field's value being a bool that
specifies whether or not the option exists on stable. Or is this adding
too much complexity?

The original changes proposed will be quite alright for covering #4798, no worries there. However, if you're interested in making any follow up proposals to improve the handling that'd be fine too! Probably worth noting that one of the many changes on the experimental v2 version actually switched over to using structopt (https://github.com/rust-lang/rustfmt/blob/rustfmt-2.0.0-rc.2/src/rustfmt/main.rs) so perhaps worth considering doing the same on the 1.x mainline

[calebcartwright]

Also for future reference I want to try to avoid merge commits as much as possible. They're strictly necessary for the sync process we use to get rustfmt pulled into the main repo for release, but outside those subtree push/pulls we shouldn't have them.

If you end up willing and interested in working on anything else it'd be best to submit the pulls from feature branches that have are up to date/rebased against the trunk branch here. Our branching strategy has been a little funky here lately too, so don't hesitate to reach out here and/or in GitHub if you have any questions!