Adding before and after filters to help debugging and do pre/post processing when needed

Use this to introduce filters to your ember objects in order to do interesting things before or after key methods are called. This is often a better option than extending and monkey-patching a method to introduce your own behaviour. 

You should use the filters like this:

```
      setup: function(context) {
        this.fbefore('setup', this, arguments)

        // do the setup

        // optionally call after, in case this method doesn't return a value
        this.fafter('setup', this, arguments)          
      }
```

Note: `fbefore` and `fafter` were chosen in order to ensure they don't conflict with `before` and `after` from observable mixin (or some other mixin).

A typical use case would be to log the state at that point without having to set break points or monkey-patching with `console.logs` directly into the ember code base. Not very nice!

For the use case where you want to log a particular aspect of Ember, f.ex the Ember.Router, you can add a `beforeAnyMethod` function to Ember.Router like this:

```
  Ember.Router.reopen({
    fbeforeAnyMethod: function(args) {
      var funName = args[0];
      console.log "before:" + funName, args.slice(1)
    },

    fafterAnyMethod: function(args) {
      var funName = args[0];
      console.log "after:" + funName, args.slice(1)
    },    
  })
```

Then you will have complete output of what goes on internally in Ember (for any method with before or after filters). You can then further make switch statements in the `xxxAnyMethod` function, in order to control for which functions you want to do something (such as logging). Powerful stuff!

Another typical use case, is when you want to wrap/convert the state of the object (or arguments) before a particular method is called. It could f.x be that you want to wrap the context object with `R` (from the RubyJS project), in order to always add the `R` API to your models or array of models. You might also want to change how Ember resolves its naming convention magic, in order to f.ex use specific namespaces in some cases to better suit your needs. 
There are many possibilities. Use your imagination ;)

_Current problem! I have problem defining a decent set of tests :(_

**The current code additions don't break anything in Ember however. All existing test pass :)**

Please help me fix the tests at:

https://github.com/kristianmandrup/ember.js/blob/after-before-filters/packages/ember-runtime/tests/mixins/filters_test.js

Thanks :)
 
```
Module Failed: mixins/filters
  Test Failed: should filter before when it has matching before filter
    Assertion Failed: beforeArgs should be set by beforeSetup filter
  Test Failed: should filter after when it has matching after filter
    Assertion Failed: afterArgs should be set by afterSetup filter
  Test Failed: should filter after when it has an afterAnyMethod filter
    Assertion Failed: Died on test #1     at http://localhost:9999/qunit/qunit.js:412
    at :125
    at :142: 'undefined' is not a function (evaluating 'this.set('afterAnyArgs', args)')
  Test Failed: should filter after when it has matching after filter
    Assertion Failed: Died on test #1     at http://localhost:9999/qunit/qunit.js:412
    at :140
    at :142: 'undefined' is not a function (evaluating 'this.set('beforeAnyArgs', args)')
```

Please let me know what you think about this feature. Thanks!