Repository: three.js
Issue: Minor Improvements to Lensflare Module
Labels: Addons

### Description

After using the `Lensflare` module a few times now and running into its limitations, I think there are a few small improvements--one I might even consider a bug fix--that may be prudent for future releases.

The "bug", so-to-speak, is in the vertex shader for the `LensflareElement` object.  The `gl_Position` variable uses the z-coordinate of the `screenPosition` uniform.  This means that sometimes the lens flare can be rendered behind objects in the scene, which doesn't really make sense since lens flares are optical effects that occur in the camera or eye.

The other issues are related to the modulation of the lens flare's size and opacity.  As it stands now, there is currently no way to change the size of the flare depending on conditions within the scene (i.e. the distance of the camera from the light source).  The case I ran into where this was a problem for me was rendering the Sun at different astronomical distances and wanting to decrease the size of the glare centered on the Sun in the animation loop depending on Sun-camera distance.  This would also be relevant to glare effects on more terrestrial scales for objects like streetlights, etc...

Similar to modulating size, one might also want to modulate opacity of lens flare elements based on the distance to the camera in a manner independent of size modulation.  A good example of this is a lens flare that is produced by the optics when light bounces around inside a camera lens.  Its 'size' as it is defined in three.js would not change based on distance.  The 'size' in screen space is based on the internals of the camera lens and the angle of the incident light.  As you move further from the light source, however, you might want to modulate the intensity (via opacity) of such a lensflare element.

### Solution

With the exception of the "bug fix", the changes I'd like to make would change nothing from a three.js developer's perspective by default.  People who have used the API previously and are comfortable with the way it currently works would see no difference (aside from proper z-placement in clip space).  The proposed changes are enumerated below:
 
1. Change the z-value of the `gl_Position` variable in the `LensflareElement` vertex shader from `screenPosition.z` to `-1.0`.

2. Add property to `Lensflare` object that exposes scale controls to the developer after creating a new `Lensflare` object and change code on what is currently Line 251 of the module to multiply the current product by this new scale property.  Also, set size/scale property to default value of 1.

3. Related to item 2, each `LensflareElement` would have a boolean parameter added to its constructor that controls whether the size/scale is affected by the change of the scale/size property of the `Lensflare` object.  This could either be `true` or `false` by default since it would only affect usage if the developer decides to mess with the scale property.  I would lean towards `true` by default so that messing around with the `Lensflare` object's size parameter by default modulates the size of the elements.  This seems like the preferable behavior.

4. Add property to `Lensflare` object that allows the opacity to be modulated in a manner that can be individually toggled between `LensflareElement` objects added to the `LensFlare` object.

5. Similar to item 3, add boolean parameter to constructor for `LensflareElement` object that determines whether changes to the new `Lensflare` opacity-modulation property affect the lens flare element.  Default to `true`.  This would include changes to the `LensflareElement` fragment shader that includes a new uniform and line to incorporate the opacity adjustment.

### Alternatives

An alternative would be to keep current functionality aside from the aforementioned "bug fix" and leave extended functionality for other developers/libraries; however, I think the proposed functionalities are fairly basic improvements considering how deep the rabbit hole goes for this topic and for how many use cases these changes would be valuable.  It still wouldn't have support for modulating size/opacity/color based on translucent occluding materials, which is something I've needed in the past but is understandably a more complex problem than probably needs to be addressed in the basic three.js lens flare module.

### Additional context

_No response_