add support for @param tags w/o a type
removed redundant test cases

These tests were actually covering the same scenario as the "param typeless"
test; but they were expecting failures (doctrine should now handle this case).
"fixed" handling of sloppy @param declarations

This is admittedly pretty hacky. The fundamental problem is that the original
code was written to enforce that @param tags must have types. This actually
isn't the case; so to fix that I added logic to check if a @param has a "type"
but no name, to cover this case:

    @param foo

In the above example the param would initially be parsed as having a "type" of
foo and no name; my fixer-up logic switched these around so foo becomes the
name and the type becomes null.

But now here is a problem case:

    @param {string} [foo]

The above is a "sloppy" declaration where foo is an optional param w/ a type of
string. Problem is that w/o the sloppy option set, parseName will return
undefined for name, which will trigger the logic previously described for
fixing the case w/ typeless params.

My solution is to handle this specific scenario at the end of next(): check for
a tag w/ a name, no type, and a description starting with '['; if this pattern
is found, revert things to the way they were. Hopefully @Constellation can come
up with a (much!) better approach for dealing with all this.
Merge pull request #16 from dtao/typeless-params

add support for @param tags w/o a type