RFC: Improve Developer iteration workflow

[lemonade-dm]

The O3D Engine suffers from slow developer iteration times as it relates to building the C++ source code base into a completed runnable target(Executable or Shared Library)

Iteration Improvement Areas

• Convert AzCore, AzFramework and AzToolsFramework into shared libraries(.dlls, .so, .dylib) in non-monolithic TARGETS
  Having the Core libraries built as dlls, would help with reducing link times of each of these libraries to Applications and Gem modules.
  Furthermore it would enforce a better public and Private API that engine developers must adhere core libraries features to the Projects and Gems.
• Split AzCore, AzFramework and AzToolsFramework into smaller libraries, based on usable roles.
  For example AzCore contains a Math directory where most of the math related functions and structures are located(https://github.com/o3de/o3de/tree/development/Code/Framework/AzCore/AzCore/Math).
  Being able to have a defined target such as O3deMath would allow downstream targets to have more fine grained approach for selecting which libraries to depend on.
  This would also reduce the amount of overall code that needs to be rebuild when these smaller libraries are changed
• Reduce the number of core gems that reside in the O3DE repo
  Currently O3DE has over 80 Gem directories in it's main repository, that would build whenever as part of a build solution whenever the 'all' target is built.
  Many developer don't build specific targets, so they have a tendency to overbuild content within the engine.
  Reducing the number of core Gems within the main repo and gems that build with Continuous Integration(CI) would help with builds times (https://github.com/o3de/o3de/tree/development/Gems).
  At the bottom of the Public API/Private API split RFC details a a set of potential Gems that can be moved from the O3DE core repo RFC: Update the Gem Templates to support a Public/Private API split #37 (comment)
• Form solutions to reduce build times in high impact areas, with many complex compile time constructs such as templates.
  The primary areas of the O3DE Codebase that needs a better build time solution are the SerializeContext, BehaviorContext, EditContext, EBus Component, AzTypeInfo RTTI system
• Tackle the ScriptCanvas files with high compile time issue where it uses templated code to reflect function pointers to ScriptCanvas Nodes.
  The amount of time that is spent in compiling ScriptCanvas nodes are massive and have huge impact on binary sizes as well
  As can be seen as follows, the ScriptCanvas and ScriptCanvas Editor static libraries are among the 2 largest libraries as it relates to binary size in O3DE.
• Reachout to @o3de/sig-content to determine how to remove the majority of slice code. There is still a need for a bit of the slice to still use with UI Canvas files, but a some of that code was duplicated and therefore should be simpler to remove.
  But shared code slice code that is being used by UICanvas might need to be moved to the LyShine Gem

[AMZN-alexpete]

This is great, I think maybe one thing to mention here because it's an underlying assumption - is that we have some standardized way of measuring various developer workflows - something we can automate ideally. I can see a separate RFC about defining and automating measuring these developer workflows in such a way that they could run regularly and feed some kind of statistics database for developers to refer to.

Defining the developer workflows may also help to clarify engine-developer vs game/simulation-developer workflows if we want to clarify what the workflows look like for engineers using, for example, the O3DE SDK vs source engine