Add TargetRailsVersion to default.yml

[searls]

After discovering that a valid configuration can't be created programmatically if it includes TargetRailsVersion without patching it in by doing an instance_variable_set on the ConfigLoader's @default_configuration, it seems appropriate to explicitly list this property even though it's specific to rubocop-rails.

For example, before this commit, running:

RuboCop::Config.create({
  "AllCops" => {
    "TargetRailsVersion" => 5.2
  }
}, "some_path")

Will emit this warning:

Warning: AllCops does not support TargetRailsVersion parameter.

Supported parameters are:

  - RubyInterpreters
  - Include
  - Exclude
  - DefaultFormatter
  - DisplayCopNames
  - DisplayStyleGuide
  - StyleGuideBaseURL
  - DocumentationBaseURL
  - ExtraDetails
  - StyleGuideCopsOnly
  - EnabledByDefault
  - DisabledByDefault
  - NewCops
  - UseCache
  - MaxFilesInCache
  - CacheRootDirectory
  - AllowSymlinksInCacheRootDirectory
  - TargetRubyVersion
  - SuggestExtensions
  - ActiveSupportExtensionsEnabled

Even though this is the domain of a plugin, it seems appropriate to add it since:

1. ActiveSupportExtensionsEnabled has similarly been added (perhaps for the same reason?)
2. RuboCop itself (and not rubocop-rails) actually contains the logic handling this setting in Config

Replace this text with a summary of the changes in your PR.
The more detailed you are, the better.

---

Before submitting the PR make sure the following are checked:

• The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• Wrote good commit messages.
• Commit message starts with [Fix #issue-number] (if the related issue exists).
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

[koic]

This is a tricky part.

1. ActiveSupportExtensionsEnabled has similarly been added (perhaps for the same reason?)

This option has been introduced for implementation convenience. For example RuboCop Rails sets ActiveSupportExtensionsEnabled: true. It's not positive, but it's a realistic solution for now. Recently suggested: rubocop/rubocop-performance#342 (comment)

RuboCop itself (and not rubocop-rails) actually contains the logic handling this setting in Config

Code around TargetRailsVersion should be extracted to RuboCop Rails, but no progress yet. Either way it would be expected to be removed from RuboCop core in future.

I'm still not sure if it's best to restore the TargetRailsVersion to the core.

[searls]

Agree that this is tricky! The division is not very clear right now which makes it a little hard to work with the API.

I was able to work around these issues for standard-rails yesterday, so there's no urgency in my request

[bbatsov]

Code around TargetRailsVersion should be extracted to RuboCop Rails, but no progress yet. Either way it would be expected to be removed from RuboCop core in future.

Agreed.