process macro chaining caused by concat correctly

hi, I love lcpp feature and use it in my project for parsing some practical library's header file (pthread.h in osx).
but lcpp did not handle macro chaining as I expected.

below quick example about my expectation.
``` lua
#define CONCAT_TEST1 foo##bar
#define CONCAT_TEST4(_baz) CONCAT_TEST##_baz
CONCAT_TEST4(1) -- I expect this valid macro definition, but it cause error like "attempt to call global 'CONCAT_TEST4' (a nil value)"

#define CONCAT_TEST5(baz) CONCAT_TEST##baz
CONCAT_TEST5(1) -- its recognize as macro. so I expect its compiled to foobar, but lcpp keep it CONCAT_TEST1

#define LCPP_NOT_FUNCTION (BAR) -- I expect this replacement macro definition, but it also recognized as functional macro
```

and it seems that this problem caused by 2 reasons. 
a) if functional macro argument name contains _, entire macro is not recognized as valid one, because regex for argument list definition only match all alphanumeric, space, and comma:
```
local FUNCMACRO = STARTL.."("..IDENTIFIER..")%s*%(([%s%w,]*)%)%s*(.*)"
``` 

b) lcpp missing re-processing token when ## is processed. for above example, after CONCAT_TEST4 processed and it compiled to CONCAT_TEST1, lcpp reprocess and compiled it to foobar.

c) FUNCMACRO allows space between macro name and arguments list. also processLine's macro processing potentially allows 1 macro definitions processed as multiple macro type (I'm not sure its needed).

I add some test case and fixing lcpp itself to pass these new test.
but this is not entirely tested for various macro usage.
so can you review this fix? 
if it seems good, I would appreciate if you could merge this to master.

thanks and happy new year!!