Repository: godot
Issue: GPU Particles' `emit_particle()` lacks clarity with the usage of the `EmitFlag` values
Labels: discussion,documentation,topic:particles

### Godot version

v4.1.2.stable; v4.2.beta4;

### System information

Windows 10.0.19045 - Vulkan (Forward+, Mobile) - GLES3 (Compatibility) - dedicated NVIDIA GeForce GTX 1650 (NVIDIA; 31.0.15.4592) - Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (8 Threads)

### Issue description

As discussed in #83245, `emit_particle()` seems to have a default implementation for position, velocity and CUSTOM.Green, but none for rotation, scale, color and the other CUSTOM values.

Even though these values are expected to be implemented by a custom particle `ShaderMaterial`, the function's description doesn't say that, resulting in a feeling that some flags are broken or lack implementation for the default `ParticleProcessMaterial`.

![emit_particle](https://github.com/godotengine/godot/assets/16827309/b0ca85be-7156-4cdf-bbee-e918bbf4f7c8)

![EmitFlags](https://github.com/godotengine/godot/assets/16827309/ed890920-211a-4eb8-8e38-8b0b9f47bd42)


From what I've seen by converting the `ParticleProcessMaterial` to `ShaderMaterial`, those values are not implemented, some of them just happens to have been injected without being overridden by the shader logic, and future implementations could change those behaviors even further.

This raises some possibilities:
1) Should all the values receive a default implementation?
2) Should it stay as is and let the docs and editor hints explain what works and what doesn't?
3) Should it stay as is and add a warning in the docs that enabling those flags could result in adverse effects on the default `ParticleProcessMaterial`?
4) Should there be a parameterless function to emit those particles that removes the need to send parameters that won't be used by the default `ParticleProcessMaterial`?

One suggestion is to implement, at least, rotation, scale and color, as they may be the ones with a higher probability of use.
This would make `emit_particle()` work (mostly) out-of-the-box, but will require that those parameters stay working in the future, which could be challenging or even impossible, given the previous discussion.

Another suggestion is to implement possibilities 3 and 4:
- Add a parameterless function to emit the particles without overriding anything. This one would be recommended for the default particle material, while the other recommended for custom particle materials.
- Leave the `ParticleProcessMaterial` implementation as is.
- Warn in the docs that those parameters are for custom `ShaderMaterials` only and could affect `ParticleProcessMaterial` in unexpected ways.
- Inform the user via the docs that they can convert `ParticleProcessMaterial` to a `ShaderMaterial` and customize it.
- Don't support if the flags are enabled while using the default `ParticleProcessMaterial`.

This seems to be the most easy and maintainable solution, making a clear statement that those flags are only for custom `ShaderMaterials`, would leave the default `ParticleProcessMaterial` free to implement things without needing to support this custom injection, would allow the user to use a function that wouldn't demand 5 parameters that won't be used and even remind them that the default implementation can be customized.


### Steps to reproduce

The MRP has "main_2d" to demonstrate the use of `emit_particle()` with a custom version of the default `ParticleProcessMaterial` that can change rotation, scale and colors, but it's by no means a good implementation and just a demonstration that it can easily be done by the user for a specific use case.

### Minimal reproduction project

[GPUParticles emit_particle.zip](https://github.com/godotengine/godot/files/13219966/GPUParticles.emit_particle.zip)