Replace vendored SIMD Everywhere by prefix/system install

[tytan652]

Description

Important

Depends on:

• Add SIMD Everywhere obs-deps#255
• Drop of the CMake legacy (I can implement legacy path if really needed)

Close #5067

Replace vendored SIMD Everywhere by prefix/system install.

SIMD Everywhere finder needs to be installed alongside libobs CMake
package since its headers depends on it.

macOS AVX intrinsics is included to make sure that AVX defines are
present.

Motivation and Context

Reduce in-tree vendored deps in OBS Studio repo.

How Has This Been Tested?

Build in CI on my fork.

Types of changes

• Code cleanup (non-breaking change which makes code smaller or more readable)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[PatTheMav]

Why do we also need to export SIMDE here? Are SIMDE types used in function prototypes or inline functions?

[tytan652]

The headers include a SIMDE header which make it a dependency of libobs header and so the CMake package needs the finder to be installed alongside the package.

[PatTheMav]

Yeah the question was more about which ones? Because SIMDE is an implementation detail of libobs internals and should not be exposed publicly. It doesn't make sense to expose it from an API point of view and if we do that seems like a mistake to me.

[tytan652]

util/sse-intrin.h (which hard depends on SIMDE) used in some installed headers:

grep -r "sse-intrin.h" /usr/include/obs/. 
/usr/include/obs/./graphics/quat.h:#include "../util/sse-intrin.h"
/usr/include/obs/./graphics/vec3.h:#include "../util/sse-intrin.h"
/usr/include/obs/./graphics/vec4.h:#include "../util/sse-intrin.h"

[PatTheMav]

Right and of course we inlined all those functions so we created a tight coupling between API users and the internal data types..

That should have never happened, but I guess that's water under the bridge and can be cleaned up once the current API is not used externally anymore in the future.