methods.test

- nsfStack.c / CallStackMethodPath(): Providing a fix for reporting method paths correctly when dispatching to ensembles from alias parameters. Prior to that fix, the intermediate (and inactive) CMETHOD frame wrapping configure() calls caused [current methodpath]s to report empty string elements. Added some test cases. - nsf.c / ObjectDispatch(), DispatchUnknownMethod(): When testing objects as alias parameter targets, I found cases when the default (C-level) unknown handler was invoked upon. The result was an unknown message which reported the delegator object as "unknown" method! This was due to injecting the delegator object into the argument vector at position 0, subsequently used by the C-level unknown handler. First, I tried to make the C-level unknown handler aware of the ensemble call context (by funneling through the CSC and frame flags) but this turned out to be complicated to achieve this simple task. As an alternative, I suggest the following patch: The first argument in unknown calls is treated as a list, and dependening on the call context (ensemble vs. non-ensemble) contains all the necessary call data. For ensemble methods, it is the delegator object, the entire method path (as returned by [current methodpath]), and the actual unknown selector. The default C-level handler, treating the call info as list, resorts to reporting the last element of the list which is always the unknown selector. Custom (ensemble-level, application-level) unknown handler can wrap and further process the information as necessary. To demonstrate the usefulness, I rewrote EnsembleObject->unknown() accordingly. I checked for Tcl_Obj leaks. - Added some tests on objects as targets of alias object parameter. To be continued.