[FEAT] Non-nullable properties in requestBody can be `null` and are not coerced into the correct type
<!--

/!\ IMPORTANT: Before opening issue

- Please update all of your packages. I won't investigate on the issue if you are on an old version.
- Please check that you have the same version for all Ts.ED dependencies (expected the logger). Many issues are related to a misconfigured packages.
- Please provide a reproducible example (avoid screenshot, prefer copy/pasted code). The stack trace isn't enough to investigate.

If theses requirements aren't checked, I WON'T INVESTIGATE (excepted if you are a PREMIUM SPONSORS!) and issue will be CLOSED!
-->

## Information

- **Version:** 7.x
- Packages:

It's possible to send in `null` as the value for string, integer and bool properties. Unexpectedly, this will not cause a validation error and the `null` will not be coerced into the correct type.

## Example

```ts
export class Test {
    @Property()
    string?: string;

    @Integer()
    integer?: number;

    @Property(Boolean)
    boolean?: boolean;

    @ArrayOf(String)
    stringArray?: string[];
}
```

Request body: 
```json
{
  "string": null,
  "integer": null,
  "boolean": null,
  "stringArray": [null]
}
```

Inside the controller:


console.log(test) logs:

```js
 {
    string: null,
     integer: null,
     boolean: null,
     stringArray: [ null ]
   }
```



This is definitely not expected behavior. The problem can be fixed by setting `coerceTypes: false` in the AJV options, however that's not what we want to do.
The problem seems to stem from the fact that the TS.ED code uses `coerceTypes: true` but then validates a deepCloned version of the object and returns the original version of the object that doesn't have the corrected types (https://github.com/tsedio/tsed/blob/production/packages/specs/ajv/src/services/AjvService.ts). Is there a reason for that?

## Acceptance criteria

- [ ] `null` should be correctly case into the correct schema type.
