An axis is innermost when it's first among those not just in its
direction, but also on its side, i.e. left/right, of the plot. So the
inArray check should be against the samePosition list, not all.
Resolves #1056.

It doesn't make sense to calculate the innermost property only when no
tickLength has been provided; the two have little to do with each other.

Resolves #1032.  Previously it was impossible to draw the same text,
with the same style, in two different locations, because the second
would end up using the first's cache entry, which only ended up moving
the element to a new position.

Now each cache entry holds a list of positions at which the text
appears, creating clones of the original element for each position
beyond the first.

Resolves #1030.  The performance impact should be low, and is the
correct thing to do in just about all cases where a plot is being
redrawn.

Resolves #1033.

 Removed executable permissions from jquery.flot.selection.js

Flot 0.7 calculated x-axis label dimensions by assigning each label a
fixed width, then measuring the height as determined by the browser.  A
side-effect of this technique is that x-axis label divs received a fixed
width.  The rewrite of the text system in 0.8 accidentally removed this
feature; this patch restores it.

The optional width parameter establishes a maximum width for the text's
bounding box, forcing it to wrap when it reaches that size.

Regression on pie plugin in the data format allowed

Patch for colors array, issue #1031

Per request from dnschnur (https://github.com/flot/flot/pull/1034#issuecomment-17119203), I have: 
- Added a comment explaining the purpose of the new check/override
- Changed the structure to match preferred standard structure

Add links between API.md and README.md

Remove $.isNumeric() for compat with jQuery < 1.7. Fixes #1026

(Realted to flot issue #1031: https://github.com/flot/flot/issues/1031)

Currently, if the user declares a custom color palette with less than 5 colors (say, n), $.extend(true, options, opts) only modifies the first n colors of the default palette and leaves the last 5-n in place. When the number of series is >n, colors are used that are not part of user-defined palette, contrary to description of colors array in API.

This line overrides the extended colors array and replaces it with exactly the user-defined colors array, when present. Afterwards, the user color palette is respected by the auto tinting/shading system for when there are more series than colors.

Remove some incorrect else-if logic in time plugin.

Avoid propagating mouse wheel events when they're first caught by the navigate plugin.

Looks like this was mistakenly introduced in a whitespace/bracket cleanup.

BUGFIX navigation wheel scrolls page.

Resolves #1016.  Initialization consists of adding the tickGenerator and
tickFormatter functions to each axis.  This should happen exactly once
per plot, but since the code was previously using the processDatapoints
hook, it was called once per series.  When no series were present, it
ran zero times, triggering an exception when we later checked for the
existence of the functions.

Binding to the processOptions hook ensures that the axes are always
modified once, regardless of how many series there are.  The axes are
already initialized by the point the hook runs, so this change shouldn't
cause any problems.

Resolves #1000.  In Flot 0.7 we only calculated tickDecimals and
tickSize once, when creating the tickGenerator for the first time.  This
meant that calls to setupGrid failed to recalculate the values, as
reported in #860.  #861 fixed the problem by moving calculation into
tickGenerator, but this turned out to cause a new problem, since the
function doesn't run when an explicit ticks array is provided.

This commit solves both by always recalculating the values outside of
the tickGenerator function.  As far as I can tell the only reason it
wasn't done this way from the beginning was to avoid unnecessary work in
the case where tickGenerator is already provided in the options.  But
the extra work is negligible, and it's actually more consistent for the
properties to always be set.

Ole's original implementation used 'middle', which I switched away from.
After a great deal of testing it turns out that 'middle' does in fact
provide the most consistent results, so we're switching back to it.