Remove implementation detail specs for Enumerator

[Earlopain]

Enumerator::Yielder, Enumerator::Generator and Enumerator::Producer are not supposed to be exposed to the user.
Instead they will interact with them trough other means, like for example Enumerator.new { |yielder| }.

Some specs I ported, others I removed, and some were already present.

I also have this PR to nodoc them ruby/ruby#17036 (they are already basically just present by name only)

[eregon]

I agree they shouldn't be documented (and merged you ruby/ruby PR) but they are still public API I would say, and based on that I think it's fair enough to test them in ruby/spec.
The are exposed to the user, e.g.:

$ ruby -e 'Enumerator.new { |y| p y }.take(1)'
#<Enumerator::Yielder:0x00007fac648b5a48>

So I wouldn't call the class names implementation details since they are public constants.

Is there something specific these specs test you think they shouldn't?

From a quick look core/enumerator/generator/initialize_spec.rb and core/enumerator/yielder/initialize_spec.rb seem rather useless except the first one checks initialize can't be called on a frozen instance which is something.
The rest looks not too unreasonable to me from a quick look.

[eregon]

In general the philosophy of core specs is "spec every public method of every public class/module" (and also some private methods like initialize). It's actually what mkspec does.

[eregon]

I do like the new specs though, so maybe we'd only remove the useless initialize specs but keep the rest?

[Earlopain]

I haven't (intentionally) removed any specs:

it "returns self" do
  y = Enumerator::Yielder.new {|x| x + 1}
  (y << 1).should.equal?(y)
end

# into

it 'can be chained' do
  enum = Enumerator.new do |y|
    y << 1 << 2
  end
  enum.to_a.should == [1, 2]
end

Which will be how people in theory actually use it. If MRI for some reason decides to return Enumerator::DifferentYielder, then nobody will really notice, except perhaps in inspect output because the name is different. Theoretically a different ruby implementation might also not implement it in this way (although I don't think that is the case, seems there is something to this approach).

I see this more like ducktyping. The concrete class doesn't matter, as long as it behaves correctly, so I rewrote the specs to how it's actually used. No one is directly instantiating Enumerator::Yielder and calling <</yield on it. But if that is how ruby-spec does it, I won't argue. Just let me know if I should still revert removing the existing specs.