Move RATE logging to attitude controller and log sample time

[andyp1per]

With RATE logging it is crucial that both the last gyro value used and the time that it was used be recorded in the log rather than whatever happens to be available at the time the log is written. In addition it makes no sense for RATE logging to be in AHRS, it really has very little to do with AHRS and everything to do with the rate and attitude controllers. This PR moves the logging functionality and records the gyro value used and timestamp at the appropriate point for logging. This is especially important when the rate loop because faster and concurrent.

Split from #27029

[lthall]

Great change but I would like to do the same thing with the ATT message.

[IamPete1]

Should be a nice clean up.

[IamPete1]

I think this looks good. The only question is if any log tools have a problem with the log timestamp not matching the time the log was written. I don't think they should. Each message should still see a increasing time. Only between messages would time go backwards. The only other thing would be if we were to write the log twice in one loop for some reason then we would get two timestamps the same.

I guess we could get round this by adding a new timestamp rather than replacing the existing one, but that would make plotting in log review tools hard as there mostly hard coded to use TimeUS on the x axis.

[rmackay9]

LGTM, thanks

As discussed on the call, a few of us are worried about the TimeUS potentially going backwards which could confuse some log analysis tools but I think it's worth the risk and it seems important that we give the devs the data they need