don't rely on [function].name

`[function].name` is not available in IE10, or any other IE version.  It returns undefined.  There are various places in the code that rely upon this property:

https://gist.github.com/bitmage/c89bcd768bbc15e5d022

I've modified types.js with one potential solution: put all the types in the Types object, and use the object key as the type name.  I don't know if this approach will apply to the broader number of use cases listed above though.

I assume that we want to support this code in the browser, and that targets should include IE10.  I expect it will take a couple iterations to get this fixed and tested.  There are several approaches we might want to use:

1.  The easy route of course is to just add the name property.  While this is generally frowned on, in this case it is unlikely to cause incompatibilities, and it could be considered a 'shim/sham' to ES6.
2. [This approach](http://stackoverflow.com/a/6903860/1846335) could be used to detect the function name, without modifying any properties.
3. Use an approach similar to what I did in types.js - keeping track of the name and corresponding function in a data structure.  This will require additional code and workarounds at various places in the code base.

Would appreciate some feedback on what the preferred approach would be.

Also, are there any thoughts on porting the test base to run in a multi-browser environment such as SauceLabs?

Thoughts as to how this might apply to the rest of the StrongLoop/Loopback toolset?

Workarounds, shims that you're aware of?  I don't see any focus on this in the shims that I'm looking at.

Thanks,
Brandon
Yeah, essentially you could do a drop in replacement at this point, and not have to modify the rest of the code.  Also, we could extract this into a helper function that could be used elsewhere:

```javascript
function getFnName(fn) {
    return fn.name || fn.toString().match(/^function\s*([^\s(]+)/)[1];
}
```

The nice thing about this is it will run fast in the common use case, and only slow down in IE.  Would there be any downsides to caching the result like this?

```javascript
function getFnName(fn) {
    fn.name || fn.name = fn.toString().match(/^function\s*([^\s(]+)/)[1];
    return fn.name;
}
```

At that point the performance would be negligible.  Even though IE may not support this property, I seriously doubt that any code is relying on its absence (because it would break in every environment *except* IE).  So caching on the name property seems safe to me.

You're right about backwards compatibility as well.  I just realized this is a publicly exported function.  So my current implementation is incorrect.