re-enabled user-defined numeric fields for dBase export

Since commit f59e350d1733125055f1144f8b3b1b0a46f6d1ca it was impossible
to define a numeric field with a precision of less than 2 decimals, even
if all values were integers. It was also impossible to define a field
width larger than needed for any values in that column. Furthermore, the
integer part was shortened if the overall column's values resulted in
more precision than defined, but the overall length did not reach the
predefined length.

This does not change the behavior of the original intention of
f59e350d1733125055f1144f8b3b1b0a46f6d1ca to give the precision of number
formats precedence over precision defined in the column header, which is
debatable though because conflicts may silently change the field
definition.

(cherry picked from commit e65141e93a540fc9fb4343ee65a5a7da7e3b1769)

Plus comment translation.

Conflicts:
	sc/source/core/data/column3.cxx
	sc/source/ui/docshell/docsh8.cxx

Backported.

Change-Id: I234c4bceaa1a6aadbd259cb8d9b6cb6f16bf91c2
Reviewed-on: https://gerrit.libreoffice.org/8809
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>
(cherry picked from commit 19d01c838c779d3326c65a798aa39cfc51bcd15e)
Reviewed-on: https://gerrit.libreoffice.org/9125
Reviewed-by: Eike Rathke <erack@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>