Allow user to specify static-width columns while bAutoWidth is enabled

[Robinson7D]

This is both for the user's flexibility, as well as performance.

Regarding performance impact, in my initial testing on a table with 500 rows, 10 columns, my machine averages ~100ms in _fnCalculateColumnWidthson initial load. Obviously, usually pagination is the best solution, but this doesn't seem like a very rare use case. If I know that 8 of those rows can be static-width, and only wish to have the other 2 calculated, and use this feature, that number is cut that down to ~26ms.

Of course, the main reason for this feature is to provide additional styling options to the user.

[DataTables]

I clean missed this before - sorry about that! Nice little hack!

I'm wondering what will happen on tables where the content is too large for the width given by the user or when there is so much content in the other columns this one gets squeezed.

I suspect it will lead to inaccuracies that could cause column misalignment when scrolling and sub-optimal layout (assuming the current algorithm gives the optimal layout, which it doesn't - although does come close I think).

As such I probably won't include it in the core, but this is a key area for optimisation!

[Robinson7D]

It shouldn't squeeze any since it uses the fallback of _getWidestNode on every column that doesn't have a static width provided. It simply prevents calling that for no reason on the columns that do have it.

Of course, I may be wrong. I can create some test jsfiddles of all extreme cases later if you would like.

[DataTables]

I'm think of cases such as if a user sets a width of 10px and then has text in the column such as "My life has been a tapestry of rich an royal hue" (i.e. it is never going to fit into 10px), then this would result in a different layout.

[Robinson7D]

Well a user would have to, for this column, both set a width, and set bResizable false (it's a new column property, and defaults to true, so this would be explicitly done by the user).

If they're doing both of those, wouldn't it make sense that either they're sure that the content will be below that width (e.g. maybe a startDate, endDate, lastLogin - all three with standard date formatting; or just a simple checkbox), or otherwise be absolutely sure that they want the column to be of the given width.

I mean, regardless of whether this PR is accepted, does a "Allow fixed-width columns while bAutoWidth is enabled" not make sense to have? There seem to be a lot of common use cases that I see, regardless of efficiency changes. Those are just a nice bonus.

[DataTables]

"Allow fixed-width columns while bAutoWidth is enabled"

That should be the case already. It takes the size given, the content from the table and tries to layout a "worst case" table.

The key change that I see is the efficiency saving from not needing to find the longest piece of data, which is both expensive and potentially inaccurate.