Make use of locale API when it becomes available

It depends. There were non-perfect things committed to core before :D There are many things in this module not fully up to date to D8 yet. Eg. we use no classes for forms, we don't use the new routing system, and so on. Some of this should be fixed before commit (I'll create issues later), but its kind of impossible to tell which. If we hold ourselves to such high standards, then we can look for new ways to do thing all the time (docs changes, form class use, etc), and we'll have stuff to update up to the API freeze date, at which point there is 0% chance to get this in core. So it all depends on what the reviewers want in short. :)

BTW based on where #1905152: Integrate config schema with locale, so shipped configuration is translated is heading, we might or might not want to use that API. That is only useful for shipped config translation, so we'd need to use two different APIs depending on where data is coming from. In #1936208: If config is translated from shipped config or partially edited, also push translations to locale storage we already want to save to two locale if we know the data comes from shipped config though, so the saving will need to be split into two ways. I'm not sure its worth doing it for the translation UI display too, but it may be more symmetric then. Anyway, we can see that when #1905152: Integrate config schema with locale, so shipped configuration is translated lands.

#1905152: Integrate config schema with locale, so shipped configuration is translated just landed. We can explore this but more important would be #1936208: If config is translated from shipped config or partially edited, also push translations to locale storage to fix soon because now the core translation system will overwrite translations submitted with this module :D

Looking at this more, I don't think this is relevant/important for us. We can use the unified override system.