[MC-277484] Particles inconsistently handle motion values from dx dy dz arguments when count is 0

When setting the count argument of /particle to 0, the dx dy and dz arguments are usually used to set motion, where speed acts as a multiplier.
This, however, is handled very inconsistently:

Totally ignores motion	Normalizes motion	Uses motion
These particles could support motion, but just ignore the passed in values, either creating them still or with fixed unchangeable motion values.	These particles take the motion values, normalize them to the same effective magnitude, and randomize and scale them a bit. You can control the direction, but not the magnitude. This is technically the default for particles according to the code.	These particles use the motion values for their motion, possibly with some additional randomness or scaling, but in a magnitude-preserving way.
`angry_villager`	`block`	`bubble`
`ash`	`composter`	`bubble_column_up`
`block_crumble`		`bubble_pop`
`block_marker`	`dolphin`	`campfire_cosy_smoke`
`cherry_leaves`	`dust`	`campfire_signal_smoke`
`crimson_spore`	`dust_color_transition`	`cloud`
`current_down`	`egg_crack`	`crit`
`dripping_dripstone_lava`	`happy_villager`	`damage_indicator`
`dripping_dripstone_water`	`mycelium`	`dragon_breath`
`dripping_honey`		`dust_pillar`¹
`dripping_lava`		`dust_plume`
`dripping_obsidian_tear`		`electric_spark`
`dripping_water`		`enchanted_hit`
`effect`		`enchant`
`elder_guardian`		`end_rod`
`entity_effect`		`firework`
`explosion`		`fishing`
`explosion_emitter`		`flame`
`falling_dripstone_lava`		`glow_squid_ink`
`falling_dripstone_water`		`item`
`falling_dust`		`large_smoke`
`falling_honey`		`nautilus`
`falling_lava`		`ominous_spawning`
`falling_nectar`		`poof`
`falling_obsidian_tear`		`portal`
`falling_spore_blossom`		`reverse_portal`
`falling_water`		`scrape`
`flash`		`sculk_charge`
`glow`		`sculk_charge_pop`
`gust`		`sculk_soul`
`gust_emitter_large`		`small_flame`
`gust_emitter_small`		`smoke`
`heart`		`sneeze`
`infested`		`snowflake`
`instant_effect`		`soul`
`item_cobweb`		`soul_fire_flame`
`item_slime`		`spit`
`item_snowball`		`splash`²
`landing_honey`		`squid_ink`
`landing_lava`		`totem_of_undying`
`landing_obsidian_tear`		`trial_spawner_detection`
`lava`		`trial_spawner_detection_ominous`
`note`		`vault_connection`
`raid_omen`		`wax_off`
`rain`		`wax_on`
`shriek`		`white_smoke`
`small_gust`
`sonic_boom`
`spore_blossom_air`
`sweep_attack`³
`trial`⁴
`trial_omen`
`underwater`
`vibration`⁵
`warped_spore`
`white_ash`
`witch`

1. Only uses dy, it ignores dx and dz
2. For some reason requires dy to be 0, otherwise it ignores dx and dz
3. Uses dx to determine its size. (This should probably be ported to a particle argument, like dust's size.)
4. Has a required target argument, which makes the particle move toward the specified location, it ignores the dxyz values still.
5. Has a required destination argument, which makes the particle move toward the specified location, it ignores the dxyz values still.

Interestingly, block{block_state:"cobweb"}, item{item:{id:"cobweb",count:1}} and item_cobweb all behave differently, despite visually being the same particles.

Objectively, the last group's behavior is the most useful to map makers, and the other 2 behaviors can be recreated with it as well.

It might be an overal good idea to move this behavior to a new argument, rather that keeping it as a count 0 special case.

To reproduce:

/particle <id> ~ ~2 ~ 0 0 1 1 0

If it stays in place, it ignores motion.
If it moves a small distance, it normalizes motion.
If it moves a large distance, it fully uses it as motion