Add fraction_field_type and define fraction_field method for fields

[fingolfin]

Seems natural and I see no harm in it?

[codecov]

Codecov Report

Attention: Patch coverage is 81.48148% with 5 lines in your changes missing coverage. Please review.

Project coverage is 88.51%. Comparing base (8ea17bc) to head (60415c6).
Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
src/Fraction.jl	55.55%	4 Missing ⚠️
src/generic/RationalFunctionField.jl	94.11%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2092      +/-   ##
==========================================
+ Coverage   88.35%   88.51%   +0.16%     
==========================================
  Files         126      126              
  Lines       31674    32702    +1028     
==========================================
+ Hits        27984    28946     +962     
- Misses       3690     3756      +66     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lgoettgens]

Can we then please also have some programmatic way for deciding the type of the fraction field of some ring, i.e. fraction_field_type that usually returns some Generic.FracField{T} thingy, but T for T being a field subtype?

[fingolfin]

I agree with the idea of adding fraction_field_type, but while looking into it I found a more serious issue:

function fraction_field(a::RationalFunctionField{T, U}) where {T <: FieldElement, U <: Union{PolyRingElem, MPolyRingElem}}
   return a.fraction_field::Union{FracField{U}}
end

And this is also documented, so we can't simply change it.

But I think that kind of throws a wrench into the idea behind this PR sigh; at the very least it would require a breaking release which renames the above fraction_field getter to e.g. underlying_fraction_field (actually I would have expect this to be base_ring, but base_ring on a RationalFunctionField is the base ring / coefficientring of the underlying fraction field / polynomial ring... sigh

[thofma]

Thanks. I expected it to be breaking, but seems to be fine.