refactoring groovy filter support

The client can now provide a groovy filter that is either a closure or is a
direct implementation of Filter. The former can be as simple as,

// simple closure filter
{ row -> if (row['value'].toInteger() > 21) return row else return null }

and the latter might look like,

// filter that directly implements Filter
class Over21 implements Filter {
  Map filter(Map row) {
    if (row['value'].toInteger() > 21) {
      return row
    } else {
      return null
    }
  }
}

GroovyFilterFactory encapsulate the logic for creating a groovy filter. If the
client script returns a closure, then the factory will wrap it in a
GroovyFilter. If the script returns an instance of Filter than that object
itself is returned. If the script returns neither a closure nor a filter, then
the factory throws an exception. In subsequent commits I will provide similar
logic for other languages.
adding initial support for javascript filters

This is a bit different from how groovy is supported. For a JavaScript filter
you have to specify a single function as follows,

function over21(row] { if (row['value'] > 21) return row else return null; }

With the groovy implementation changes I made in 47737c4a4 you can define an
entire script, and the return value is assumed to be the filter. The JavaScript
version is different because the ECMA spec considers it illegal to have a
return statement outside of a function. But similar to a groovy script, the last
line of a javascript script is the return value of the script; so, it might be
possible to make behavior more consistent. For now though I am inclined to
leave it as is until I see how things look for other languages.

The other thing to point out with this commit is some of the work done in
JavaScriptFilter. A java.util.Map passed into a script is not treated as native
javascript object; so I first convert the row method argument into a
javascript object that is then passed to the function. JavaScript objects do
however implement Map so there is no conversion required for the return value
from the script function.

Lastly, integration tests have been updated as well.
encapsulate filter factory logic in FactoryProvider

The work of determing which factory to use is now delegated to
FactoryProvider, which could be extended with similar logic for creating
processors.
Merge pull request #93 from jsanda/filter-lang-support

Refactor CREATEFILTER and add additional language support