feat: support custom formvalue function

[li-jin-gou]

Some gin or net/http services have a different formvalue function when migrating to fasthttp.
it maybe causes some bugs.

net/http:

// FormValue returns the first value for the named component of the query.
// POST and PUT body parameters take precedence over URL query string values.
// FormValue calls ParseMultipartForm and ParseForm if necessary and ignores
// any errors returned by these functions.
// If key is not present, FormValue returns the empty string.
// To access multiple values of the same key, call ParseForm and
// then inspect Request.Form directly.

The user can customize a formvalue function to avoid this problem, but it would be better if the framework provided this switch.

[erikdubbelboer]

Do you have a real world example of this going wrong or is it something you think might go wrong?

[erikdubbelboer]

Suggested change

	type FormValue func(*RequestCtx, string) []byte
	type FormValueFunc func(*RequestCtx, string) []byte

[li-jin-gou]

done

[erikdubbelboer]

Suggested change

	func SetStandardFormValueFunc() {
	func SetNetHttpFormValueFunc() {

[li-jin-gou]

done

[li-jin-gou]

Do you have a real world example of this going wrong or is it something you think might go wrong?

Yes, there was a problem with the code in the real environment and I noticed the difference. the front end passes the same parameters and different values in the http body and query and result in an unintended bug...😩

[erikdubbelboer]

This field needs some documentation since it's exposed.

[li-jin-gou]

thanks and done

[erikdubbelboer]

Suggested change

	// NetHttpFormValueFunc Consistent behaviour with net/http. POST and PUT body parameters take precedence over URL query string values.
	// NetHttpFormValueFunc gives consistent behavior with net/http. POST and PUT body parameters take precedence over URL query string values.

[li-jin-gou]

thanks

[erikdubbelboer]

Thanks!