Merge pull request #200 from redding/jcr-system-tests

Basic stub system tests, instance and singleton methods
Add readable inspect to `Stub`

This adds a readable inspect to `Stub` to help with cleaner
output. Since asserts stubbing now writes instance variables, the
default inspect for objects will show the stubs that have been
written to an object. This would inspect the instances of `Stub`
on the object which would show all of its instance variables. The
output of this was noisy and difficult to read. This cleans up
the output and makes it simpler to read.
Merge pull request #201 from redding/jcr-stub-inspect

Add readable inspect to `Stub`
Stub system tests for mixed in and inherited methods

This adds some system tests for stubbing methods that are either
mixed in (via include or extend) or inherited. The goal is to
throughly test assert's stubbing in the same way it would be used
in a separate test suite and to find any strange issues that can
come from mixing stubs or using them in strange scenarios. These
include edge cases and error cases that ensure assert's stubbing
tries to alert the users to possible issues as much as possible.
The biggest difference for these kinds of methods is for extended
or inherited class methods assert doesn't check arity when
stubbing or calling the method. For included or inherited instance
methods it does check arity.

This also adds system tests for stubbing a method on a class and
a class that inherits from it. In this case, it stubs `new` on
both the parent class and the child class and ensures they can
be stubbed individually without effecting the other.
Merge pull request #202 from redding/jcr-non-local-method-system-tests

Stub system tests for mixed in and inherited methods
Stub system tests for mixed in and inherited methods

This adds some system tests for stubbing methods that are either
mixed in (via include or extend) or inherited. The goal is to
throughly test assert's stubbing in the same way it would be used
in a separate test suite and to find any strange issues that can
come from mixing stubs or using them in strange scenarios. These
include edge cases and error cases that ensure assert's stubbing
tries to alert the users to possible issues as much as possible.
The biggest difference for these kinds of methods is for extended
or inherited class methods, assert doesn't check arity when
stubbing or calling the method. For included or inherited instance
methods it does check arity.
Stub system tests for delegated methods

This adds some system tests for stubbing methods that are delegated
(via `method_missing`). The goal is to throughly test assert's
stubbing in the same way it would be used in a separate test suite
and to find any strange issues that can come from mixing stubs or
using them in strange scenarios. These include edge cases and error
cases that ensure assert's stubbing tries to alert the users to
possible issues as much as possible. For delegated methods, assert
doesn't provide any arity checking of the methods. This is the
only difference between stubbing a normal method and a delegated
method.