from line 54

(Fingers crossed!)

From line 51

Per feedback from @arbonap, we've added a sentence that briefly explains what binstubs is to the binstubs section.

[2.0] Stop remembering CLI options in Bundler 2

### What was the end-user problem that led to this PR?

The problem was that on Bundler 1.0, command line options passed to the different commands would be remembered _across command invocations_. This was hella confusing for users, and made Bundler a difficult command line tool to work with -- you'd pass an option once, it'd be set without you realizing it, and Bundler would behave differently.

See https://trello.com/c/yGsPNDpg/48-stop-auto-remembering-any-command-flags for the original discussion, but I've excerpted bits below:

> Silently remembering flags that were passed to a command sometime in the past completely breaks all expectations for how command-line utilities work. It’s convenient for some users some of the time, but at the cost of many, many bugs filed that turn out to be unexpectedly remembered options.

### Was was your diagnosis of the problem?

My diagnosis was that, behind a feature flag, we'd change commands behavior to only set settings temporarily (for the life of the current process), and after that disable options that become useless when not remembered.

See https://github.com/bundler/bundler/pull/3955.

### What is your fix for the problem, implemented in this PR?

My fix is to remove most CLI options in Bundler 2. Those that remain are set only for the duration of the process, rather than persisted to disk.

Stop gitignoring Gemfile.lock in default template

This will be followed up with a documentation PR on some best practices to keep gems tested against up to date dependencies.

### What was the end-user problem that led to this PR?

The problem was that sometimes open source contributors get discouraged because they can't setup the project they want to contribute to easily.

### Was was your diagnosis of the problem?

My diagnosis was that a lot of projects gitignore `Gemfile.lock` just because it's gitignored by default in the new gem template. This causes `bundle install` to no longer be guaranteed to work. And `bundle install` is usually the first step towards a contribution.

### What is your fix for the problem, implemented in this PR?

My fix was to remove the `Gemfile.lock` entry from the gitignore template.

### Why did you choose this fix out of the possible options?

I chose this fix because to prevent a file from being gitignored, removing it from the `.gitignore` file usually does the trick :)