Fix helper specs with internal classes

[fables-tales]

A rebase of #1340. Got a few more things to fix up.

[JonRowe]

LGTM, whats still outstanding?

[fables-tales]

There's this from @cupakromer #1340 (comment) but maybe we already fixed it? @cupakromer can you weigh in here?

[fables-tales]

I want to rewrite this boolean expression to read with less complexity.

[JonRowe]

I'm still not groking why theres two different names for these methods

[fables-tales]

these have to be rails hooks

[cupakromer]

Ok, I remember what I was thinking before. It was more a question of does this make conceptual / semantic sense, not that I had a problem with the implementation.

Essentially, the nested group will have :type => :helper - with all of the helper stuff mixed into it - even though it is not specing a helper. I think before this concerned me as it will bloat and slow the nested group unnecessarily. It also may be misleading for tools / plugins that look for :type => :helper.

I did some basic sanity checking tonight and I don't have any real problems with this. My initial concern about the metadata and what goes along with it still stands but it's not something I feel is a blocker. There is one corner case that may be confusing to people:

# I ran this using Rails 4.2.5 and rspec-rails 3.4.0
require "rails_helper"

module FooHelper
  def foo_helper
    :foo
  end

  class InnerClass
  end
end

RSpec.describe FooHelper, type: :helper do
  def self.determine_default_helper_class(_ignore)
    return unless Module === described_class && !(Class === described_class)
    described_class
  end

  specify "#foo_helper returns :foo" do
    expect(helper.foo_helper).to be(:foo)
  end

  describe FooHelper::InnerClass do
    it "it has a helper" do
      expect(helper).to be
    end

    it "the helper does not have behavior like the parent group's" do
      expect {
        helper.foo_helper
      }.to raise_error(NoMethodError)
    end
  end
end

[fables-tales]

@cupakromer I think that is a an edge case that we're unlikely to encounter, given that this is already a fix for an edge case. @cupakromer @JonRowe is this good to merge?

[cupakromer]

Yeah good to merge. My concern isn't a blocker. Do you think there's a way to leverage Configuration#define_derived_metadata? Or would that potentially change metadata semantics too much to be even more confusing?

[fables-tales]

@cupakromer I think changing metadata semantics in a minor version is a bad idea. I think we should revisit when we start work on 4.0 proper.