Properly handle boolean flags in HTTP querystrings

[scottinet]

Description

HTTP querystrings do not define how boolean values should be encoded, how they are handled depend on the API parsing the querystring.

Kuzzle's convention is that, for booleans, option values are irrelevant. Instead, a boolean option is truthy if it' set in the querystring, and falsey otherwise.

So this: url?foo=0 or url?foo=false makes Kuzzle interpret the foo option as a non-empty string, and thus as "true" when converted to a boolean.

This PR fixes how the SDK passes boolean options to the querystring, only setting one if it's truthy, and skipping it if it's not.

How to test it

Use Kuzzle's CLI createFirstAdmin command: even if you tell it to not reset anonymous rights, it resets it because of that bug. If you apply these changes, the CLI acts as expected.

Other changes

Add a missing unit test about how arrays are encoded in the querystring.

[benoitvidis]

nitpicking: do we really need the comment block and the nested if?

else if (typeof value === 'boolean' && value) {
  // foo=false => foo is truthy
  queryString.push(key);
}

[scottinet]

We need the nested if because, otherwise, a falsey boolean value will be processed by the final else condition just below, and added to the querystring anyway