Keep track of last matrix activity

[tzarc]

Description

This PR adds support for recording the last time matrix activity was detected.
Two new APIs have been added:

uint32_t last_matrix_activity_time(void);     // Timestamp of the last matrix activity
uint32_t last_matrix_activity_elapsed(void);  // Number of milliseconds since the last matrix activity

These values are compatible with normal matrix scanning, as well as split_common.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[tzarc]

@mtei any other concerns, or are we happy with a merge?

[mtei]

It looks like it's working properly. There seems to be no problem.

However, I'm not sure the significance of moving 'transport_master()' into 'matrix_pre_scan()'.

Current matrix.c timing (click)

This PR's matrix.c timing. (click)

[tzarc]

However, I'm not sure the significance of moving 'transport_master()' into 'matrix_pre_scan()'.

@mtei Been a while since I looked at this PR, but I believe it was so that the full matrix is made available at the time matrix_scan_quantum is invoked -- matrix_scan_kb and matrix_scan_user then have an up-to-date view of the slave matrix.

EDIT: Re-investigating, I don't think this is an issue with the old behaviour -- will sort out rollback of that specific portion.

[tzarc]

Newer, simpler implementation seems to work fine.