Respect system animation setting

[michaelschattgen]

This pull request adds logic to properly respect the systems animation settings. Since I had to go through all the different animations we currently have in our app there is a possibility I might have missed one, let me know in case I did.

Fixes #930.

[alexbakker]

This patch gets us closer, but we're still not fully respecting the animation settings. For each of these animations, I think we should simply multiply the duration by ANIMATOR_DURATION_SCALE. This way the animations get disabled if the setting is set to 0 and in other cases the duration is properly scaled. We already do this for the TotpProgressBar and I think it makes sense to do the same here.

The exception being the preference transition animations. I think it's correct to multiply by TRANSITION_ANIMATION_SCALE instead there. Figuring out how to change the duration there was a bit of a Google rabbit hole, but adding the following to PreferencesFragment and IconPacksManagerFragment seems to do the trick:

@Override
@Nullable
public Animation onCreateAnimation(int transit, boolean enter, int nextAnim) {
    if (nextAnim != 0) {
        Animation anim = AnimationUtils.loadAnimation(getActivity(), nextAnim);
        float amimDurationScale = Settings.Global.getFloat(requireContext().getContentResolver(), Settings.Global.TRANSITION_ANIMATION_SCALE, 1.0f);
        float duration = anim.getDuration() * amimDurationScale;
        anim.setDuration((long) duration);
        return anim;
    }
    return super.onCreateAnimation(transit, enter, nextAnim);
}

Also, I think the intro slide transition animations are not covered yet.

[michaelschattgen]

You're right, for some reason I thought my first commit would cover the issue. I've changed everything to a more generic way where the current scale gets taken into account instead of a 'on' or 'off' state.

As for the intro slides I've decided to let that rest for a bit since that requires more effort that I initially thought.