Commit generated default dependencies as they're read

Closes #1284. 

- Move `this._computedBindings = {}` out of `_setupComputes` and into
  `setup`
- Overwrite `_get` in `_setupDefaults` to set defaults with `this.attr`
  when they're read in defaultGenerators
- Prevent the calling of a defaultGenerator if its value is passed in on
  instantiation
- Create a test for reading defaults with `this.attr` in
  defaultGenerators
- Create a test for defining defaults on instantiation
Here's what I can tell you: 

- The `_computedBindings` object was being populated after the defaults where processed
- Committing properties to `.attr()` while processing defaults meant `_computedBindings` needed to be defined earlier on, so it was moved to `setup`
- `can.List` and `can.LazyMap` define their own `setup` method 
- From what I can tell `can.List` and `can.LazyMap` do not call `can.Map`'s `setup` method
- Since `_computedBindings` is no longer defined in `_setupComputes`, anything that extends `can.Map` with its own `setup` method is now responsible for defining the `_computedBindings` object
- Instead of defining `_computedBindings` in all of the `setup` methods it may have made more sense to simply call `_setupComputes` before `_setupDefaults`
- Calling `_setupComputes` before `_setupDefaults` didn't seem like an option at the time because `_setupComputes` appeared to be dependent on the defaults:

  ```js 
  var defaultValues = this._setupDefaults(obj);
  this._setupComputes(defaultValues);
  ```
- In reality `_setupComputes` isn't actually using any of the arguments passed to it  

I think I've talked myself into moving `_computedBindings` back into `_setupComputes`, removing the `_computedBindings` definitions in `can.List.setup` and `can.LazyMap.setup`, not passing `defaults` to `_setupComputes`, and changing the order that `_setupDefaults` and `_setupComputes` are being called. 

Theoretically that should all work just the same. 

Standby for a new commit.