Fix Cycles CUDA kernels for Ampere not building with CUDA 11

Running Blender on Ampere cards was already possible with ptx, this fix is
needed to support building CUDA binaries.

Note the CUDA version used for official Blender builds is still 10, this is
merely the change to make it possible for those using CUDA 11 and specifying
the sm_8x kernels to be compiled.

Found by Milan Jaros.

Cycles: hack make update to build this temporary branch with 2.83 libraries

Cycles: Add CUDA 11 build support

With this patch the build system checks whether the "CUDA10_NVCC_EXECUTABLE" CMake
variable is set and if so will use that to build sm_30 kernels. Similarily for sm_8x kernels it
checks "CUDA11_NVCC_EXECUTABLE". All other kernels are built using the default CUDA
toolkit. This makes it possible to use either the CUDA 10 or CUDA 11 toolkit by default and
only selectively use the other for the kernels where its a hard requirement.

Reviewed By: brecht

Differential Revision: https://developer.blender.org/D9179

Cycles: Enable OptiX on first generation Maxwell GPUs again

Fix OptiX being shown as available on first generation Maxwell GPUs

The OptiX kernels are compiled for target "compute_sm_52", which is only available on second
generation Maxwell GPUs, so disable support for older ones.

Cycles: Use pre-compiled PTX kernel for older generation when no matching one is found

This patch changes the discovery of pre-compiled kernels, to look for any PTX, even if
it does not match the current architecture version exactly. It works because the driver can
JIT-compile PTX generated for architectures less than or equal to the current one.
This e.g. makes it possible to render on a new GPU architecture even if no pre-compiled
binary kernel was distributed for it as part of the Blender installation.

Reviewed By: brecht

Differential Revision: https://developer.blender.org/D8332

Cycles: Enable OptiX on all Maxwell+ GPUs

Version bump: Blender v2.83.12 release

Blender v2.83.11 is skipped due to unable to uploading to the windows
store.

GPU: Enabled hq normals workaround for any AMD driver on polaris

GPU: Enable HQ normals workaround for AMD 21.1.1 driver.

AMD 21.1.1 still has the same issues as reported in T82856.

Buildbot: Fixed crash when building RC builds

Building RC builds would parse `BLENDER_VERSION_CYCLE_NUMBER` that
doesn't exist anymore. It was removed by {D7748}.

This change removes it from `buildbot_utils.py`.

Version bump: Blender v2.83.11 rc

Particles: Fixed thread work size calculation.

Dividing the workload by number of tasks in float is imprecise and
lead in some cases to particles not being calculated at all
(example: 20000 particles, 144 tasks).

Switching this calculation to integer makes sure we don't lose count.

Differential Revision: https://developer.blender.org/D10157

Fix T79356: Improved icons for MSIX builds

Fixed an issue that was causing the app icon to render with a
'plated' background color in the taskbar and other areas of Windows.

Updated all app icons in Microsoft Store package to match Microsoft's
design recommendations.

Added multiple scales for app icons for high resolution displays.

Added high contrast app icons.

Reviewed By: pablovazquez, jmonteath

Maniphest Tasks: T79356

Differential Revision: https://developer.blender.org/D9681

Fix: Update normals when switching scene quality

Recent commits also updated normals for metaballs, curves and volumetric
objects. This change tags will tag to generate geometry for these new
types.

Fix T84397: Creating and removing many objects very quickly causes a crash

The root of the issue was caused by the dependency graph using ID pointer
to map evaluated state from old depsgraph to new one upon relations update.
This was failing when IDs were re-allocated rapidly: was possible that
Object ID's evaluated state assigned to Mesh and vice versa.

Now depsgraph uses Session UUID to identify which IDs to restore evaluated
state to. The session UUID is stored in the IDNode, so that id_orig is not
dereferenced on depsgraph update since the ID might be freed.

The root of the issue is identified by Campbell, original patch was done
by Bastien, thanks! Also thanks to Oliver and Ray and everyone else for
testing!

Fix T84459: Wireframe not displaying with AMD GPU

Issue appears to be caused by AMD graphics driver later than 20.11.1 and
affects older GPUs (Polaris/FIJI cards). Wireframe drawing uses the same
OpenGL data type for storing normals what is known to be faulty.

This patch enabled storing the normals using GPU_COMP_I16. It also
solves the normals drawing in edit mode for vertex and loop normals.

Fix T84459: Face normals not displaying (AMD GPU)

This is part two of the fix for T84459.
Issue appears to be caused by AMD graphics driver later than 20.11.1 and
affects older GPUs (Polaris/FIJI cards). Drawing normals in edit mode
uses the same OpenGL data type for storing normals that is known to be
faulty.

This change fixes the face dot normals by using GPU_COMP_I16.

GPU: Enable HQ normal work around for AMD Polaris

THe high quality normals work around is enabled for Polaris cards using
the official drivers. Since driver version 2.11.2 they fail to render
using low quality normals.

The detection of polaris cards is done by matching the opengl renderer.
The renderer strings have been extracted from various reports linked to
{T82856} but isn't complete as some reports are missing the exact
renderer as users don't always report via the help menu.

GPU: Add HQ normals workaround.

This change makes it possible for platforms to only support high quality
normal rendering. This is part of {T82856} where current AMD drivers
running on the polaris architecture does not support the low quality
setting due to a driver bug.

In a next commit the work around will be enabled.