PM-runtime: Switch accounting over to ktime_get_mono_fast_ns()

Similar to what happened whith autosuspend, a deadlock has been
reported with PM-runtime accounting in the call path:

change_clocksource
    ...
    write_seqcount_begin
    ...
    timekeeping_update
        ...
        sh_cmt_clocksource_enable
            ...
            rpm_resume
                update_pm_runtime_accounting
                    ktime_get
                        do
                            read_seqcount_begin
                        while read_seqcount_retry
    ....
    write_seqcount_end

Make PM-runtime accounting use ktime_get_mono_fast_ns() to avoid this
problem.

With ktime_get_mono_fast_ns(), the timestamp is not guaranteed to be
monotonic across an update of timekeeping and as a result time can go
backward. Add a test to skip accounting for such situation which should
stay exceptional.

Fixes: a08c2a5a ("PM-runtime: Replace jiffies-based accounting with ktime-based accounting")
Reported-by: Biju Das <biju.das@bp.renesas.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
[ rjw: Subject, changelog, comment cleanup ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>