Make sampler creation optional when loading textures

[SaschaWillems]

Description

This PR adds a new argument to the texture loading functions of the api samples base class that allows to skip default sampler creation. With this change samples that use custom samplers for certain textures (shader object, terrain tessellation) no longer need to delete the sampler that would've been implicitly created when loading the texture. This results in cleaner, easier to understand code.

Fixes #866

General Checklist:

Please ensure the following points are checked:

• My code follows the coding style
• I have reviewed file licenses
• I have commented any added functions (in line with Doxygen)
• I have commented any code that could be hard to understand
• My changes do not add any new compiler warnings
• My changes do not add any new validation layer errors or warnings
• I have used existing framework/helper functions where possible
• My changes do not add any regressions
• I have tested every sample to ensure everything runs correctly
• This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

• I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
• My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

[gary-sweet]

I can't actually run either of the two samples affected, but the change looks ok.

[asuessenbach]

You probably wanted to also call load_texture[_array] for terrain_array_textures and heightmap_texture in the terrain_tessellation sample with the non-default value of false for the new last argument?

Besides that, as the only difference between the default sampler and the locally generated samplers is the addressMode, you might as well add that as an optional argument to load_texture[_array], similar to how it's done in the hpp-version of those functions?
Or otherwise change the hpp-version of those functions accordingly, to make them logically equivalent, again?

[SaschaWillems]

Will have to check. I tend to forget that I need to change stuff like this in two places. Maybe I'll defer this to after we have unified the framework :/