Dev: New `.datatables-commit-sync` which is going to be used by the
build and commit scripts to keep the src and build repos in sync.

Dev: Update the dataTables main file to the latest build which was
accedentally committed. Just a couple of little dev fixes - no API
changes.
Dev: Update CSS file with the updated formatted used in the source repo
API: Column selector now allows `{integer}:visible`

- This is an alias of `{integer}:visIdx` which should be a little easier
  to remember.
Build: Package desciptors now held in a common location and built as
part of the build process.
Build: Usage for the make script
Dev: Fix issue whereby you couldn't order with a click on a column after using order() API

Fix: I've removed the third entry in the aaSorting array, as the issue
was that after using order() that entry wasn't present. It was a bit
confusing as well, so it is now replaced with a property (_idx on the
aaSorting entries) which indicates the current sorting index (in
asSorting) - and this property is optional. If not given, it is looked
up or 0.
Dev: Sync to 5e444c7e09126c87965e69873fc5152fd097014b - the build script
was having a few sync issues
New: cache() methods for rows and cells.

- I'd previously added columns().cache() which gets the cached
  information about filtering or sorting, but this rounds the API off,
  extending that also to rows and cells:

  - rows().cache()
  - row().cache()
  - cells().cache()
  - cell().cache()
API: Static methods updated for DataTables 1.10 camelCase

- Alias the static methods to camelCase and hungarian varients:
  - versionCheck()
  - tables()
  - isDataTable()

- Small updates in styling of the static functions
Update: When Ajax loading data, now automatically ajust column sizing

- Previously you'd need to use initComplete and columns.adjust() to take
  account of the data that was loaded by Ajax. Now this will be done
  automatically. It does mean a few more clock cycles, but I think
  that's a tradeoff that is worth it.
Dev fix: Volumne visiblity with scrolling enabled would misalign columns

- When creating the new visiblity methods, I forgot to have the table do
  a scroll draw to have the columns align correctly for the header and
  body. This commit fixes that.

- Also update the column visiblity example to use jQuery events rather
  than DOM0 events.
Dev styling: Lighten selected paging button colour

- Reversed the hover and active paging colours as the black was rather
  heavy by default
API: Update to extension API for camelCase support and tidy up

- This is a fairly far reaching commit in that the DataTables.ext object
  is updated to primarily use camelCase, just like the rest of the 1.10
  API. The old notation is still available for compatiblity, but
  deprecated.

- While working in this area, I've made a number of updates:

  - .model.ext has been removed - that was redundant and not useful.
    DataTables.ext is where the plug-ins for DataTables will live and
    will be correctly publically documented as such.

  - Type based actions (detection, sorting and filter) now live in a
    `type` namespace to make it clear that they are type based.

  - Internal references to .ext updated to use the new parameters. We
    could use the old ones since they are fully backwards compatible,
    but I'd rather set the standard by using the modern ones.

  - JSDoc comments for .ext updated

  - Extension examples updated
Dev fix: Single column sort when not shift clicking the column

- If you were multi-column sorting, and didn't have shift depressed and
  click on the first column in the sorting priority, the multi-column
  sort would be retained. Non-shift click on any of the other columns
  would reduce to a single column sort, so match here
Dev fix: Fix dependency for bower
Dev fix: oApi backwards compatiblity issue

- The oApi option wasn't being attached correctly to either the settings
  object or the instance, so plug-ins were breaking. This adds the alias
  back in.
Update: Rewrite of column type detection

- Automatic column type detection was a real weak point of v1.9- - it
  did basically work, but if you then updated a row that didn't match
  the current data type it would always end up as a string. A good
  example of this is the ambiguous date "06-06-13" (is it dd-mm-yy or
  mm-dd-yy?). If it was detected as dd-mm-yy and then you add '05-20-13'
  to the column (or update an exisiting cell), the type would not match
  the exisiting value that thus failover to a string.

- Type detection is now more rigorous, but still optimised (since it
  has the potential to take up a significant amount of time). When a row
  is added or updated, or a cell is updated, the exisiting type is
  removed from the target column(s) and then, before sorting or
  filtering, the _fnColumnTypes function checks to see if any column
  needs to be type detected and do so if needed. This approach allows
  multiple rows to be added (for example) before the draw is performed and
  the type actually needs to be calculated.

- In future I'd like to have a 'data-ready' type event which will tell
  DataTables, and any of its components that something wants to work with
  the data in the table and it should prep the data. The counterpart would be
  a 'data-invalid' flag which would be set on update, add etc so it knows
  when an update is needed.
Size: Remove `_fnColumnOrdering` and replace with a _pluck call
Dev styling - darken the paging button border slightly
Update: If there is no sorting methods for the column type, use string

- In the case of filtering, if there is no filtering extension for the
  column type, then the basic string based filter formatting is
  performed (i.e. string is always the fallback - there can't be an
  error because a function isn't there).

- This commit matches that behaviour in sorting. If you define a column
  type as something for which there is no column sorting function, then
  the string type will be used rather than resulting in a javascript
  error.