Consistently adopt EvolutionPoint

[alecandido]

Even after #242, there are still places in which we could make use of an EvolutionPoint (i.e. it would be the conceptually correct object), but we keep passing just a scale, and optionally a number of flavors (optionally both because it may default to None, but even because we may not allow for it at all).

E.g.

eko/src/eko/couplings.py

Lines 712 to 716 in 431a055

	def a(
	self,
	scale_to,
	nf_to=None,
	):

where clearly (scale_to, nf_to) = target: EvolutionPoint.

This propagates down to the Atlas, that sometimes has to deal with an unspecified number of flavors, and it is the reason for the Atlas.normalize() function.

eko/src/eko/matchings.py

Line 66 in 431a055

self.origin = self.normalize(origin)

eko/src/eko/matchings.py

Line 139 in 431a055

mu2f, nff = self.normalize(target)

• use EvolutionPoints consistently
  • especially in eko.couplings and eko.msbar_masses
• drop Atlas.normalize()

[felixhekhorn]

This is related to #248

[alecandido]

This is related to #248

Almost: that's another instance, but a special one, because it is part of our minimal public API.

Actually, here I'd like to address everything but that one in particular :)