feat(common): improve extensibility on few built-in pipes

[micalevisk]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

The built-in ParseEnumPipe has a protected method (isEnum) that would help devs on considering if a value is a valid enum, see:

nest/packages/common/pipes/parse-enum.pipe.ts

Lines 51 to 63 in 85bda83

	async transform(value: T, metadata: ArgumentMetadata): Promise<T> {
	if (!this.isEnum(value)) {
	throw this.exceptionFactory(this.validationErrorMessage);
	}
	return value;
	}
	protected isEnum(value: T): boolean {
	const enumValues = Object.keys(this.enumType).map(
	item => this.enumType[item],
	);
	return enumValues.includes(value);
	}

but ParseBoolPipe, ParseFloatPipe and ParseIntPipe doesn't has such capability

What is the new behavior?

By implemeting the Template Method pattern, when extending some of those pipes listed above, one could define how they want to evaluate some value as a valid value to proceed the transformation.

For instance, currently, ParseBoolPipe will transform "true" to true, but what if we want to treat "1" as true as well? we would have to write our own pipe or write some normalization logic in the transform method.
Now we could easily extend the built-in pipe like this:

class MyParseBoolPipe extends ParseBoolPipe {
   protected isTrue(value: string | boolean): boolean {
      return value === '1' || super.isTrue(value)
   }
}

To summary, this PR adds ParseBoolPipe#isTrue, ParseBoolPipe#isFalse, ParseFloat#isNumeric and ParseInt#isNumeric. All returns boolean.

Does this PR introduce a breaking change?

• Yes
• No

I'm not 100% sure on this because devs could have extended some of that pipes and write a method on them that will override the newly added methods, which can lead to unexpected behavior (I guess?)

[coveralls]

Pull Request Test Coverage Report for Build 29c53980-ed9c-44d3-bf74-7e66129c69a0

• 8 of 8 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.002%) to 94.046%

---

Totals
Change from base Build 0a7dce2a-d55f-4ed3-96fe-535d2466a616:	0.002%
Covered Lines:	5765
Relevant Lines:	6130

---

💛 - Coveralls

[micalevisk]

side note: idk why we're checking if typeof value === 'number' as value:string but I didn't change this because I'm unsure if value could be number somehow

Maybe we need to adjust the type def of value here and in ParseIntPipe too?