Correctly re-install extensions when running `pristine` for a git source

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

I have a gem with a native extension that is installed via git. I had to recompile it due to some needed build arguments.

### The problem was...

Running `bundle pristine` would not recompile it as expected.

### My diagnosis was...

After digging into the source, I discovered that the built extension lived in a different location than the cloned git repo. `bundle pristine` was only removing the git repo so the built extension was not getting rebuilt.

### My fix...

Update `bundle pristine` to also remove the built extension. For 2.0, this also required removing the built extension cache. Without doing that, the built extension directory would just be recreated from the cache.

### I chose this fix because...

As far as I know, it's the only solution.

Resolves #6294

[SpecGroup] Remove unused ivar

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

The problem was this ivar was unused.

### What was your diagnosis of the problem?

My diagnosis was we should remove it. For performance, you know.

Handle updating a specific gem for a non-local platform

Fixes https://github.com/bundler/bundler/issues/6350.

Kudos to @segiddins for the test.

Fix some rescue calls that do not specifiy error type.

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

The problem I noticed was in style, several instances of `rescue` clauses that do not specify an exception type. This is noted in in the Ruby Style Guide as [Avoid rescuing the Exception class](https://github.com/bbatsov/ruby-style-guide#no-blind-rescues).

### What was your diagnosis of the problem?

My diagnosis was that at least some of those are leftover style. They are noted in `.rubocop_todo.yml`. To make sure, I asked on Slack.

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

My fix is to make as many of them more specific, specifying at least `StandardError`, and trying to be more specific.

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

No other ways of addressing this came to mind. I'd be happy to consider.

Explain spec files and output a link to bundler.io guides

Resolves #6246

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

1. There is no helpful comment about `spec.files` method in a new gem's gemspec.
2. `$ bundle gem gem_name` is missing link to further reading about developing, testing and releasing the newly created gem.

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

1. Add a comment in the `newgem.gemspec.tt`
2. Add a message after new gem generation with link to [bundler.io guides](https://bundler.io/guides/creating_gem.html)

Example:
```bash
๛  ~/code/oss/tmp $  ../bundler/bin/bundle gem new_gem
Creating gem 'new_gem'...
      create  new_gem/Gemfile
      create  new_gem/lib/new_gem.rb
      create  new_gem/lib/new_gem/version.rb
      create  new_gem/new_gem.gemspec
      create  new_gem/Rakefile
      create  new_gem/README.md
      create  new_gem/bin/console
      create  new_gem/bin/setup
      create  new_gem/.gitignore
Initializing git repo in /Users/nesaulov/code/oss/tmp/new_gem
Gem 'new_gem' was successfully created. For detailed information on further steps please visit https://bundler.io/guides/creating_gem.html
๛  ~/code/oss/tmp $
```

Fix to check if stderr was closed before writing to it

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

See https://github.com/bundler/bundler/issues/6190

### What was your diagnosis of the problem?

The error is happening because we're not checking if stderr is closed prior to writing to it.

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

My fix is to add a check to determine if stderr was closed.

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

I chose to fix it here for a start and discuss with others if more checks were needed. Maybe we need to check if stderr is closed for all references of `$stderr.puts` and replace `abort` with `$stderr.puts` and `exit(1)`?