Merge pull request #13 from dtao/master

fixed handling of '*' followed immediately by a blank line
Parse regular /* comments as well as jsdoc-style /** comments
Use one regex for both jsdoc and regular block comment open token
Merge pull request #14 from demands/regular_block_comments

Parse regular /* comments as well as jsdoc-style /** comments
version 0.1.1-dev starts
handle default param values
Merge pull request #15 from petebacondarwin/default-param-values

Handle default param values
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.