[NFR]: Bump up the work factor of security->hash()

[Ruzgfpegk]

Is your feature request related to a problem? Please describe.
Not a problem, rather a security enhancement.
In Security.zep, the default work factor for bcrypt is set to 8:

cphalcon/phalcon/Security.zep

Line 58 in a48b319

protected workFactor = 8 { set, get };

The Perils of the default bcrypt cost factor article by Clio Labs is what made me question this value.
As I learned through this article, 8 is the value that was suggested 20 years ago, and computing power has improved quite a bit since then.
PHP uses a default value of 10, which means that, again by default, using Phalcon's security->hash instead of PHP's password_hash leads to passwords that are 4 times weaker; +1 to the work factor leading to a twice slower, so twice more robust, hash generation.

This article advised for a value of 12 three years ago (it would probably be higher today), but it may not be suitable for everybody as a default value.

Describe the solution you'd like
Bumping up the default work factor for bcrypt to at least 10, like PHP does by default.

Describe alternatives you've considered
Well of course it's up to people to adjust this setting themselves while developing, and relying on default values that can change over time may not be a good idea if you're not aware of them, but having a more secure default value for this setting would be nice.

Additional context
I encourage people to check the benchmarks on the mentioned article, they're a well-needed reality check, not even mentioning the fact that core count increased a lot recently in consumer-level CPUs.

[ruudboon]

I don't see an issue aligning this with the PHP default factor or higher. @niden @sergeyklay any thoughts?

[sergeyklay]

I'm ok with this.

[niden]

Resolved in #14552

Thank you @Ruzgfpegk