[Feature] Add support for the precision parameters to the FLOAT field
Ehh, I'm going to pass on this, as I think it could be misleading. This is a mysql-only thing, as far as I know, and the data is still stored as a floating-point (e.g. approximate) value anyways. If you want to specify a precision then you would really want to use the DecimalField (numeric type).

I'd suggest adding your own subclass of FloatField to your libraries if you want this functionality. That makes sense, thanks for taking a look at it! I had thought that this was a mysql+postgres feature, but it looks that you're right and it's only mysql. Thanks again for the great library!
Hello, thank you so much for creating and maintaining this library! Peewee has been my go-to for several years now, both at work and on personal projects and it's honestly been a joy to use.

Recently I encountered a situation where I needed to specify the [precision parameters](https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html) for the MySQL `FLOAT` field, and after a search through this repo and the docs I ended up opening a [question on Stackoverflow](https://stackoverflow.com/questions/67475853/specify-float-column-precision-in-peewee-with-mariadb-mysql) where I got a very helpful answer that this patch is based on.

---

This patch adds two new init parameters to the `FloatField` class:
* `max_digits`, which corresponds to the `M` precision parameter on the MySQL `FLOAT` class and defines the number of digits that can be returned accurately from the column
* `decimal_places`, which corresponds to the `D` precision parameter on the MySQL `FLOAT` class and defines the number of digits after the decimal point which can be returned accurately from the column

Currently each of these new parameters has a default of `None` and are excluded from the return value of `get_modifiers()` so that the current behavior of the field isn't changed. However, if the defaults were changed to `max_digits=6` and `decimal_places=0` then the current behavior would be changed but the behavior of the field would be consistent across database backends.