What does this PR do?

TLDR: Convert Atom_RPI.Public and Atom_RPI.Edit to shared libraries and fix all upstream (mostly in AzCore) problems. Feedback needed on whether the MSVC warning 4251 could be disabled globally. In comparison to the reverted PR18315, this PR does not export all symbols but only those which are explicitly marked for export.

Detailed changes

• Create new files Configuration.h which contain the export macro definitions
• Add export macros (ATOM_RPI_PUBLIC_API, ATOM_RPI_REFLECT_API, ATOM_RPI_EDIT_API) to class declarations in Atom_RPI
• Add AZ_DLL_EXPORT macros to explicit template specializations of exported template functions
• Remove GetBuildTimestamp() in ShaderVariant/ShaderVariantAsset because the implementation in ShaderVariantAsset was missing
• Change ViewGroup::m_cameraViews from vector to array, because the ViewData struct is not copy constructible (it uses AZ::Event)
• Move ResourcePoolSourceData::Reflect to new cpp file (was in ResourcePoolBuilder.cpp, which is a different cmake target)
• Some small changes like defining a default constructor in the cpp file (this is mostly necessary for the nounity-build)
• Add new dll AzCore which publicly depends on AzCore.Static, this dll now contains the explicit instanciations of some templates (like DECLARE_EBUS_INSTANTIATION(...)). This dll depends on AzCore since instantiating an ebus uses many things from AzCore, so it cannot easily be moved to O3DEKernel; and with this constellation no downstream targets need to be changed. The explicit instanciations must be in a shared library, since otherwise the linker complains about multiple definitions of a template in different dlls/exes, which violates the ODR and cannot be resolved like inside of a single dll/exe. This seems to be a problem in general when a static library is linked into multiple dlls which are then linked again into another dll or exe.
• Add new AZ_DLL_EXPORT_EXTERN and AZ_DLL_IMPORT_EXTERN macros since Clang on Linux requires an additional dllexport when declaring an extern template, but Clang on Windows and MSVC dont allow this
• Move template functions in AZ::Internal::IdHandler/AZ::Internal::NonIdHandler/AZ::Internal::MultiHandler ouside of the class definition such that externing them works correctly (this is mostly due to linker errors (*IdHandler), and in one instance about crashes when an EBus context is accessed from multiple modules, eg. when the codepath from an EBus broadcast is handled in different modules): This works for the most part, the downside is that AZ::Internal::NonIdHandler and ::IdHandler also need to be externed with a extern template class Internal::IdHandler... in addition to the EBus itself, and since using directives cannot be used for extern template class (extern template class EBus<SystemTickEvents>::BusesContainer::Handler is not allowed (it works in MSVC but is not allowed according to the standard, and doesnt work with Clang on Windows), as well as eg. AZStd::conditional<...> which uses using as well), there are now two separate macros required for declaring and instanciating an extern EBus (one for Id, one for NonId). I didnt find a way to get the id/nonid information from the class with template magic, since not being allowed to use a using directive limits template metaprogramming significantly.

Feedback needed

• Disable the warning 4251 "'type' : class 'type1' needs to have dll-interface to be used by clients of class 'type2'": This PR only compiles when disabling this warning globally (it would be possible to use the AZ_PUSH_DISABLE_DLL_EXPORT_MEMBER_WARNING/AZ_POP_DISABLE_DLL_EXPORT_MEMBER_WARNING macros to disable this warning more locally for the affected classes (of which there are many) if this is not an option). I dont really see the point of keeping this warning enabled, since it is disabled a total of ~350 times in the codebase; mostly due to Qt classes, but it would also needed to be used in any Atom::RPI class which contains AZStd::* members or members from AzCore, such as intrusive_ptr (until AzCore is a shared library itself). So I would suggest to disable this warning globally.
• The macros DECLARE_EBUS_EXTERN_DLL_SINGLE_ADDRESS and similar ones are not really that pretty, but it does not seem to be possible to get the correct members to declare as extern template due to the using limitation of the extern template syntax. Maybe someone could think of a better way to handle this?
• I dont really know what is going on with RPI::SceneNotificationBus and RPI::ShaderReloadNotificationBus: It works fine with the unity build, but lead to linker errors (IdHandler::~IdHandler already defined in CommonFeaturesAtom.Editor.Static) when using a nounity build. The workaround is to declare the bus as extern with the DECLARE_EBUS_EXTERN_DLL_MULTI_ADDRESS macro, but I dont know why this is necessary (could be any of: template instantiations are not deduplicated across dll boundries, a derived dllexported class exports the handler, the functions are not implicitly inline, the functions are not exactly the same in all translation units due to changes in compile options, or something completely different; it is very difficult for me to get a complete picture of the EBus and related classes to see where the problem could be, and since it is all template code it should just work™, but obviously it does not). This being necessary only for the SceneNotificationBus with nounity-build suggests that some specific constellation of defining handlers and dispatching events leads to problems, so it could be a problem for other RPI buses which are used in external gems.

Future work

Based on the large number of AZ_PUSH_DISABLE_DLL_EXPORT_BASECLASS_WARNING/AZ_POP_DISABLE_DLL_EXPORT_BASECLASS_WARNING that needed to be added, and some linker errors which are likely due to static AzCore being linked into multiple dlls, it is probably advisable to convert the core libraries (AzCore/AzFramework) first and then move outwards to other targets and gems for future work (which is also suggested in the "Improve Developer iteration workflow RFC").

How was this PR tested?

Run the Editor and do some interactions, run tests locally on Linux, run the AtomSampleViewer and look at a few samples