SQLi bypass with surrounded square brackets

Almost any kind of injection, when surrounded by square brackets, can bypass the check.
For example:
```
1337 INTO OUTFILE ‘xxx’--
vs
[1337 INTO OUTFILE ‘xxx’--]
```
makes its fingerprint become 'n',
```
111=@`\'`)%20UnIon%20seleCt%201,2,3,4,5,6,7,8,9,10,userid,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,pwd,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42%20from%20`%23@__admin`%23@`\'`%20
vs
[111=@`\'`)%20UnIon%20seleCt%201,2,3,4,5,6,7,8,9,10,userid,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,pwd,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42%20from%20`%23@__admin`%23@`\'`%20]
```
its fingerprint becomes 's'.

By a quick look into lexer I found following handling of `[]`:
```C
/**
* This handles MS SQLSERVER bracket words
* http://stackoverflow.com/questions/3551284/sql-serverwhat-do-brackets-mean-around-column-name
*
*/
static size_t parse_bword(struct libinjection_sqli_state * sf)
```

This can be a defeat.

I've tested with 3.9.2 and 3.10.0.

Start in the lexer at parse_bword, the entry point identified in the report for handling square-bracketed words. Reproduce the two supplied inputs with and without surrounding brackets and inspect how their fingerprints differ. Done means bracket-surrounded SQL injection is no longer able to bypass detection; no test file is named in the issue.

Written by the indexing model from the issue text.