A bit of refactoring, bug fix and feature

I fixed a bug where due to the usage of the word's index in s:interestingWords.
Since mid is gotten through 86750+n, where n is the length of the s:interestingWords list + 1, when we uncolor a word the list gets shorter so n ends up being reused. This results in an id already being used error. I have fixed this by using a dictionary where the keys are the words and the values are the mids. s:interestingWords is now a list where the indexes of 0 indicate that the color is not taken and more importantly indicate the n value to generate mid is not taken.

A bit of refactoring around, mainly to reuse code and make it flow more logically.
Calling InterestingWords() checks if the word is already colored and performs Color() or Uncolor() instead of Uncolor() being nested in Color(). Argument passed to Color() and Uncolor() changed to the word itself rather than getting the \<cword\> in both functions. UncolorAll just calls Uncolor() on all the s:interestingWords.

Changed the value of n to get mid from 86750 to 595129 (random prime) as I believe 86750 is being used in some .vimrcs and some other plugins e.g. Mark.vim.

New feature - when max number of highlight reached, uncolor a previous highlight and apply that color to the new highlight. The color is chosen is the least recently used one.
```
let g:interestingWordsCycleColors = 1
```

Included handling of ignorecase + smartcase. A 'bug' arises when ignorecase and smartcase are both on and we highlight a word that matches 2 highlight groups. e.g. 'foo' and 'Foo'. Pressing n on 'foo' leads to 'Foo' due to smart case. However, 'Foo' cannot lead to 'foo' despite being in the same highlight group since 'Foo' does not match 'foo' in smart case.
This unintended behavior can be prevented by specifying the case option
```
let g:interestingWordsCaseSensitive = 1    " or 0
```
where 1 forces case sensitive and 0 forces case insensitive.

Really like this plugin!