Route aggregate queries in transaction grouped mode through the correct layer...

Route aggregate queries in transaction grouped mode through the correct layer to remove deleted transactions (#247)

I recently migrated my personal usage of Actual over to the open-source
version and imported a bunch of transactions. I have a _lot_ of history
in Actual, including a lot of weird edge cases like deleted split
transactions. While reconciling I noticed that my account balance shown
at the top was incorrect, even though the running balance was current.

Digging into this, I discovered that we aren't correctly handling
aggregate queries when querying transactions in the "grouped" mode.
Aggregate queries don't make sense in the "grouped" mode. Grouped means
that you want a list of transactions that include both the parent and
child transactions (when they are split). If you are summing up all the
amount, you only want to consider non-parent transactions. So we switch
it back to "inline" mode, but the way we did this previously was to
manually stitch the query together.

Even though was add SQL to ignore deleted transactions, we still
possibly include them. A child transaction may not be marked as deleted,
even though the parent transaction is deleted. When a parent transaction
is deleted, all child transactions should be considered deleted as well,
regardless of their tombstone status. This is what the
`v_transactions_internal_alive` view does. Previously we weren't going
through this view though, so we could still potentially include split
transactions even though they've been deleted.

This is little hacky, but it fixes the immediate problem. We fall back
to the inline mode by modifying the where clause, and we also adjust the
view that it queries to use the correct one.