Replacing `qs` with `qs-esm` or `picoquery`

[Fuzzyma]

I want to propose to move from qs to qs-esm or picoquery.

qs seems to pull in a lot of dependencies that are not needed in your specified engine anymore

qs-esm has the same engine requirements than the newest body parser version. However, since require(esm) will most likely not be available for node 18, picoquery seems to be the only viable solution.

I would be happy to create a PR if you are on board with this.

[dpopp07]

This is related to #453 (discussion around custom parameters for qs)

Also, worth noting that current usage of qs includes more configuration options than are supported by picoquery:

body-parser/lib/types/urlencoded.js

Lines 165 to 174 in 80fbb76

	return qs.parse(body, {
	allowPrototypes: true,
	arrayLimit: arrayLimit,
	depth: depth,
	charsetSentinel: charsetSentinel,
	interpretNumericEntities: interpretNumericEntities,
	charset: encoding,
	parameterLimit: parameterLimit,
	strictDepth: true
	})

(For reference, these are the options supported by picoquery) :

{
  nesting: true,
  nestingSyntax: 'dot',
  arrayRepeat: false,
  arrayRepeatSyntax: 'repeat',
  delimiter: '&'
}

[wesleytodd]

This has been brought up a bunch of times, and I dont have time right now to go find all my responses, but the TLDR is that I remain unconvinced that transitive dependency count is a metric we want to optimize around. If you can make a case which is more comprehensive around the performance impact of installs then please do so, but this conversation has pretty much stalled out every time I have asked this of anyone in the past.

edit: found this which I think this was the most comprehensive issue opened so far: expressjs/express#5723