ShaderModule::single_entry_point()

[Firestar99]

Almost all of your userbase* will have a single glsl file, containing a single shader, generating a single *.spv file which contains the sole entry point main. And it's loaded like this:

vs::load(device.clone())
            .unwrap()
            .entry_point("main")
            .unwrap();

I'm annoyed at constantly having to write that the entry point is main. I know there is only a single entry point in that file, so just give me that one, without me having to write main every time. This PR adds a function just for that, simplifying the code above to:

vs::load(device.clone())
            .unwrap()
            .single_entry_point()
            .unwrap();

rust-gpu, or why I actually wanted this

Rust-gpu by default compiles all shaders into a single *.spv with varying entry points. However your shader! macro does not like that, so typically users will turn on "multimodule" which generates one *.spv per shader. But the entry point name will still be the rust module path to the shader function, eg. renderer::lodobj::vs, and specifying that is even more annoying. I've solved it by codegening all the shader! macro calls in the build script, where I have access to both the spv file path and entry point name, so I won't benefit from this PR anymore, but others using glsl will probably like this as well.

Testing

The other entry_point() methods are only covered by unit-tests through shader cache tests. And with the shader! macro not being available in tests it seems pretty difficult to automatically test.
So I've just reverted to manually testing the single_entry_point method in the triangle example, but testing the single_entry_point_of_execution may prove difficult as glslc will not generate an spv with multiple entry points from what I can tell.

Checklist

1. Update documentation to reflect any user-facing changes - in this repository.

2. Make sure that the changes are covered by unit-tests.
   See Testing

3. Run cargo fmt on the changes.

4. Please put changelog entries in the description of this Pull Request
   if knowledge of this change could be valuable to users. No need to put the
   entries to the changelog directly, they will be transferred to the changelog
   file by maintainers right after the Pull Request merge.

   Please remove any items from the template below that are not applicable.

5. Describe in common words what is the purpose of this change, related
   Github Issues, and highlight important implementation aspects.

Changelog:

### Additions
- Added `ShaderModule::single_entry_point()` which may replace `entry_point("main")` calls in common setups.

[Firestar99]

I wonder if most ShaderModules are just a single entry point anyway, if ShaderModule::entry_point_map: HashMap could be removed and entry points searched linearly though the entry_point_infos vec? Also should it be a smallvec of size 1?

[marc0246]

We put self in backquotes everywhere else in the library (and parameters in general).

[marc0246]

I wonder if most ShaderModules are just a single entry point anyway, if ShaderModule::entry_point_map: HashMap could be removed and entry points searched linearly though the entry_point_infos vec? Also should it be a smallvec of size 1?

Sure, I don't see a reason to have both fields, even when it you have multiple entry points. The end goal is to use ShaderModule to get your EntryPoints out once and then never again. No point caching anything inside ShaderModule itself. But I don't see the point of the SmallVec since this is the last place to optimize.

[Firestar99]

about SmallVec: if I'm already removing the entry_point_map may as well also integrate SmallVec and save a heap allocation, need to change the same code for both anyways.

[marc0246]

LGTM, thanks!