Add option to explicitly set the base class

[fcofdez]

There are some problems creating a pull request from issue using hub. It returns 500 error, so I've decided to create a new pull request.

[coveralls]

Coverage remained the same when pulling 7b8514f on fcofdez:base-object into 1d41c1e on avdi:master.

[dragosmiron]

I think this test might give you a false positive. Correct me if i'm wrong, but even if clone and dup don't work, they would still return nil because that's what this gem does.
I think clone should be tested around the freezed state of the new object

[dragosmiron]

Also, instances of singleton can't be duped or cloned

[fcofdez]

I was trying to keep coherence with the original gem behaviour, because if we don't mock dup and clone methods it will return an TypeError when we call dup or clone methods. Maybe the correct way of doing this should be letting singleton class to raise TypeError on dup or clone calls.

[avdi]

I think the specdoc might be a little misleading. It is important for null objects to appear to be copyable, since they may well be asked to stand in for an object which is copyable. However, as you note, Singleton disables copying. These tests exist to ensure that we override the default Singleton behavior, and deliver a null object which acts like it is copyable.

Although actually now that I read this again, I think the current behavior is wrong; it should really return self from dup and clone, not nil. That way code that expected to be able to dup/clone some "real" object will Just Work with a singleton null object.

[fcofdez]

I think you are right, in my opinion Coherent behaviour should return self from dup and clone.

[coveralls]

Coverage remained the same when pulling 93dab1e on fcofdez:base-object into 1d41c1e on avdi:master.

[avdi]

Thanks! I changed the base class setting to be an accessor and merged.