Update `build_query_vars_from_query_block` to handle new `taxQuery` structure

[ntsekouras]

In GB we've updated the structure of Query Loop's taxQuery to also handle exclusion of terms in this PR (​https://github.com/WordPress/gutenberg/pull/73790).

The new structure is:

{
	query: {
		taxQuery: {
                         include: {
				category: [1, 2, 3],
				post_tag: [10, 20]
			}
			exclude: {
				category: [5, 6],
				post_tag: [15]
			}
		}
	}
}

We need to update build_query_vars_from_query_block to handle this new taxQuery structure.

Trac ticket: https://core.trac.wordpress.org/ticket/64416

In GB we've updated the structure of Query Loop's taxQuery to also handle exclusion of terms in this PR (​https://github.com/WordPress/gutenberg/pull/73790).

The new structure is:

{
	query: {
		taxQuery: {
                         include: {
				category: [1, 2, 3],
				post_tag: [10, 20]
			}
			exclude: {
				category: [5, 6],
				post_tag: [15]
			}
		}
	}
}

We need to update build_query_vars_from_query_block to handle this new taxQuery structure.

For the previous migration, we converted the old format to the new prior to constructing the query.

We do the same with $tax_query here. Eventually they are added in $query['tax_query']. Did you mean something else?

I think migrating will make it easier for future developers following the code so I'd suggest doing so here.

As this is the third change to the taxQuery format, it might be worht doing it in a serate function wp_migrate_query_block_tax_query_or_something()

I thought about that while implementing this, but I felt it's better to keep it as is because:

1. The first migration had completely different props used, while this one changes the internal structure of query.taxQuery. With that, it feels more readable and easier to follow IMO because we check for if ( ! empty( $block->context['query']['taxQuery'] ) && is_array( $block->context['query']['taxQuery'] ) ) { once and then we have an if/else block for both structures
2. It's unfortunate how the dynamic blocks deprecations are handled (code lives forever in this file), but since I had to do this change, I wouldn't expect any more deprecations in the future for this attribute.

Said that, if you have a strong opinion on this I can update, but I don't feel it will make much difference personally.