Added custom prefix support for widget getSkinName
Build for widget getSkinName custom prefix support
First try at changing the cell formatter,
mostly for the purpose of discussing it with others.
Merge branch 'master' of git://github.com/yui/yui3 into 2533034
Slightly changed the logic to apply column formatters.
Changed the name of the formatter function hash to Formatters.
Deleted a few unused arguments to keep the linter happy.
Added the datatable-formatters module
Merge branch 'master' of git://github.com/yui/yui3 into 2533034
Moved the formatters from DataTable to DataTable.BodyView,
which is the one actually using them.
Added some API documentation.
Formatters property is now declared explicitly in BodyView.
The API docs was expanded to explain the varios options for
the column `formatter` definition.
Updated the landing page to mention the named cell formatters.
Merge branch 'master' of git://github.com/yui/yui3 into 2533034
Added testing of formatters
This caused a bunch of errors in the formatters, which were fixed.
Took out all the input elements from the formatters

These caused a lot of confusion in YUI2 because they
didn't have any code to commit those changes to the record.
Fixed all the errors signaled by JSHint in Shifter.

Mostly trailing whitespace, a few long lines in API docs,
some unused arguments and a few more issues.
Added missing semi-colon
Build for widget skin missing semi-colon
Update Base's benchmark.js setup.
[WIP] Lower-level fix to improve new BaseCore() times. Store cfg in State by reference, since the we already isolate it higher up in the API.
[WIP] Initial drop for cached ATTRS aggregation across instances, to speed up construction for > 1 instance use case.

* attribute, attribute-core, base, base-core unit tests all pass.
* app, widget, widget-parent/child, dd tests all pass.

Benchmark sample, on Chrome 23

3.8.0

MyBaseCore with 20 varied attributes (using perf. best practices) x 11,805 ops/sec ±1.89% (89 runs sampled)
MyBaseCore with 20 varied attributes x 7,039 ops/sec ±3.74% (73 runs sampled)
MyBaseCore with 10 simple value attributes x 21,069 ops/sec ±1.66% (93 runs sampled)
MyBaseCore x 60,417 ops/sec ±2.23% (90 runs sampled)
BaseCore x 61,683 ops/sec ±0.92% (86 runs sampled)

This commit

MyBaseCore with 20 varied attributes (using perf. best practices) x 20,857 ops/sec ±1.94% (94 runs sampled)
MyBaseCore with 20 varied attributes x 9,384 ops/sec ±4.12% (71 runs sampled)
MyBaseCore with 10 simple value attributes x 36,140 ops/sec ±2.03% (92 runs sampled)
MyBaseCore x 78,936 ops/sec ±3.45% (89 runs sampled)
BaseCore x 81,023 ops/sec ±2.64% (90 runs sampled)

This is an initial baseline pass to validate:

1) The potential benefits of the approach.
2) The feasibility of the approach - by fully passing unit test suites.

The focus was on making sure we have passing feature tests, there by establishing
the minimal performance savings available, without compromising stability.

That is, we should be able to get *at least* this much savings, but likely more,
since we may be over-isolating some of the configs/default values, based on the focus
to have passing tests.

Next Steps For BaseCore:

a) Look into isolation code paths, to make sure we're optimially isolating cfgs and default values, and
   not iterating more than we need to.

b) Look at some lower-level, potentially micro optimizations to speed up the Attribute->State interface,
   maybe leveraging ES5 where available.

Next Steps for Base:

a) Optimize Event firing/publishing for the "No Listeners" path, so new Base() approaches new BaseCore()
Micro Optimizations, plus cleaning up ATTRS cache a little.

Key wins seem to be:

a) Avoiding the delete operator, and just set to undefined/false
b) Using cfg by reference where possible (as opposed to getting/setting in state again)

As a result of a) had to update an attribute test for the _getAttrCfg protected method, since
we leave more internal meta-properties in the attr config hash (instanced of deleting them).

attribute, base, widget, dd and app tests all pass.

NOTE: We can get a bit more of a performance boost, once we clean up app's id handling to avoid
the addAttr overide (we need to update one of of state's internal meta-properties [lazy],
for that, which we could avoid). Without this, there was a failing model-rest-sync test
(discussed with Eric).

This commit (Chrome 23):

MyBaseCore with 20 varied attributes (using perf. best practices) x 24,336 ops/sec ±1.70% (93 runs sampled)
MyBaseCore with 20 varied attributes x 9,748 ops/sec ±5.56% (64 runs sampled)
MyBaseCore with 10 simple value attributes x 51,166 ops/sec ±1.91% (93 runs sampled)
MyBaseCore x 159,111 ops/sec ±1.58% (94 runs sampled)
BaseCore x 164,114 ops/sec ±1.69% (94 runs sampled)

Last commit (ATTRS cache):

MyBaseCore with 20 varied attributes (using perf. best practices) x 20,857 ops/sec ±1.94% (94 runs sampled)
MyBaseCore with 20 varied attributes x 9,384 ops/sec ±4.12% (71 runs sampled)
MyBaseCore with 10 simple value attributes x 36,140 ops/sec ±2.03% (92 runs sampled)
MyBaseCore x 78,936 ops/sec ±3.45% (89 runs sampled)
BaseCore x 81,023 ops/sec ±2.64% (90 runs sampled)

3.8.0:

MyBaseCore with 20 varied attributes (using perf. best practices) x 11,805 ops/sec ±1.89% (89 runs sampled)
MyBaseCore with 20 varied attributes x 7,039 ops/sec ±3.74% (73 runs sampled)
MyBaseCore with 10 simple value attributes x 21,069 ops/sec ±1.66% (93 runs sampled)
MyBaseCore x 60,417 ops/sec ±2.23% (90 runs sampled)
BaseCore x 61,683 ops/sec ±0.92% (86 runs sampled)