Add unit tests on contribution recur trxn_id, contribution recur processor id

This is preliminary cleanup towards exposing cancel_reason as a search field, as committed to in proposal to
add the field. This change

- adds unit tests for the trxn_id & processor_id fields
- makes the handling of them more generic
- adds contribution recur field data to the contribution query object so it can be accessed.

Some points about the last of these. Basically we have a situation where the query object needs metadata to
avoid field by field handling. We have done this is some wierd & wonderful ways with dependencies on 'import' &
'export' metadata info to the point where they were given to so many fields as to become meaningless.

I think this method is better - ie. just adding the additional metadata to the query class for all the entities it
deals with. A recently merged PR means 'where' data is still available using this method.

Also I have added uniquenames to the contribution recur fields. Uniquenames no longer really matter outside
- the query object
- profiles
- possibly import & export

We only really expose recurring contribution info through the query object of these so it should be safe. In a future happy
space apiv4 & namespacing will render uniquenames a distant memory.

I couldn't rip out the special handling entirely without dealing with the labels that go into the qill. I figure
we should merge this & then address that - but briefly the issue is that Matt has just changed all the labels
to not quite work in this context so we need to discuss / agree how to manage 'Recurring Contribution Trxn ID' vs
'Trxn ID'.

I also didn't want to rip out the special handling fully in advance of https://github.com/civicrm/civicrm-core/pull/14118
being merged as there could be a performance regression if we let more code hit that unnecessary join line