Fix price change blocks affecting running average
## Summary
Price-change-only blocks (revaluations) were incorrectly affecting the running average denominator in the single-currency register path. After a price-change block, subsequent months used an incorrect (too small) denominator, making averages appear higher than they should be.
## Regression test
`price-change-not-counted-in-average`: A simple case with a transaction in Jan, a price change in Feb, and a transaction in Mar. The average at Mar should be 220/3 = 73.33 (3 months elapsed), but was showing 220/2 = 110.00 because the Feb price-change block didn't increment the block counter.
## Root cause
In `groupSingleIntoBlocks`, when a block had no transactions (only price changes), `nextBlockNum` was set to `effectiveBlockNum` (unchanged) rather than `effectiveBlockNum + 1`. This meant the price-change block "consumed" a time slot without advancing the counter, causing all subsequent blocks to have their denominators off by one for each price-change block encountered.
Additionally, the average for the price-change block itself used `effectiveBlockNum - 1`, pretending the block didn't exist. This is incorrect: every block represents a time period and should count toward the average.
## Fix
Removed the `hasTransactions` conditional: `nextBlockNum` is now always `effectiveBlockNum + 1`, and the block's own average always uses `effectiveBlockNum`. The `isTransactionEntry` helper is no longer needed and was removed.
## Things to manually check
- Review the updated golden outputs for the 33 affected tests, especially:
- `convert-year-filter.txt` (the originally reported case)
- `end-date-price-change.txt`
- `price-change-later.txt`
- `prices-no-transactions-convert.txt` (edge case: blocks with only price changes)
- Confirm that the `price-change-not-counted-in-average` test clearly demonstrates the fix