V0.4.2 adds a few bug fixes and enhancements, greatly improved RDoc output, and internal
refactorings to improve performance.

Bug fixes:
15202 Intermittent confusion between classes and objects when invoking advice
19262 Just putting join_point argument in advice block causes mysterious method missing error.
19321 Advice overhead is too high (ongoing improvements)

Enhancements:
13403 Support recursion into nested types without requiring "tricky" regular expressions
13406 "Sugar" for adding methods and attributes to types
18537 Provide a search for all pointcut constants
19666 Improve the RDoc output
19119 Provide an "after_raising" type of advice that lets you handle the exception.

#15202: I never figured out the cause of this problem, but it hasn't been seen since late last
year, so I suspect it disappeared as a side effect of on-going refactoring and enhancements.

#19262: If you just specified "|jp|" for an advice block, you would sometimes get a method missing
error. I never figured out exactly why, but it was somehow related to passing the usual three
arguments internally, where the last two would be ignored in this case. Now, the code checks the
arity and only passes the join point in this case.

#19321: I removed some of the wasted object creation and initialization in advice invocation,
improving the overhead by about 40%. However, it is still at least 10x higher than simple method
aliasing, so I want to make more improvements. (I did not close this item.)

#13403: I added new options :types_and_nested_types and :types_and_nested that are analogous to
the similar "ancestors" and "descendents" options. The nested option will return the specified
types and any types they "enclose". There are also corresponding "exclude" options.

#13406: I've decided not to do this, as it really isn't the "simplest thing that could possibly
work." It's easy enough for the user to define a module of new behavior and just use
"obj.extend(module)". However, when the user needs to do this over a set of types, Aquarium's
TypeFinder can be helpful, so I added an example to the Examples code and page.

#18537: I've provided an example of the design approach where you define pointcuts in a class,
as a kind of "aspect interface" and write aspects that specify those pointcuts. The problem has
been that you had to name every single such pointcut explicitly. There was no "finder" option,
as for types, methods, etc. Now there is a pointcut finder option with a new option
":named_pointcuts" for Aspect.new to specify a search for pointcuts in a set of types matching
a name specification. Either constants or class variables will be matched (or both).

#19666: The rdoc for the key classes was cleaned up so it "renders" better. Feedback is welcome.

#19119: I finished the previously-incomplete support for allowing advice to change the raised
exception, in both after and after_raising advice. A common scenario is to wrap the thrown
exception in another. For example, a low-level, service-specific exception (like a database
error) in a higher-level, more generic application exception.

You still can't rescue the exception completely in after_raising and after advice; the value
for the exception in
joinpoint.context.raised_exception
when the advice returns will be raised by Aquarium. I think that permitting after_raising or
after advice to "eat" the exception could cause subtle issues with scope and variable binding.
It would also probably violate the "principle of least surprise"; the advice code that rescues
the exception would not be as "obvious" to the reader as the familiar idiom of rescue clauses
that we are accustomed to using. Therefore, if you want to recover completely from an exception,
use rescue clauses in around advice.