Add contributing guide

Document should cover:

• The structure of this repo
  • It contains the starter project, game headers with modding edits, stubs with modding edits, stub assets, SML mod, AccessTransformers editor time plugin, SMLEditor editor time mod, ExampleMod mod, Alpakit editor time plugin
  • https://docs.ficsit.app/satisfactory-modding/latest/Development/BeginnersGuide/StarterProjectStructure.html
• Expectations for testing
  • Content should work on windows clients, windows servers, linux servers
  • Test locally on all the platforms you can before opening a PR
• Expectations for implementing things in blueprint versus c++
• Code style (UE Style)
• Discuss on the Discord with the team first - not all features belong in SML
  • Examples of things that usually do:
    • Hooking enhancements
    • General systems to improve cross-mod compatibility
    • Access transformers or blueprint-callable helpers for C++ functions that would benefit every mod trying to extend the game
    • ExampleMod examples of SML or base-game features
    • Developer utilities in SMLEditor
  • Examples of things that usually don't:
    • New resources or machines
    • Changes to base game behavior, even fixing bugs (https://ficsit.app/mod/FixReliableBufferOverflow)
    • Something that would prevent vanilla clients from joining an SML server
    • Access transformers or blueprint-callable helpers for C++ functions that only certain mods would need
    • Runtime tests (these go in https://github.com/satisfactorymodding/SMLFeatureTests)
• Supporting merged content
  • We won't merge changes that we can't reasonably support in the future

Start by reviewing the repository structure described in the issue and the linked Starter Project Structure guide. Draft a contributing guide covering testing platforms, Blueprint versus C++, UE style, team discussion, suitable contributions, runtime-test boundaries, and long-term support expectations; it is done when each listed expectation is documented clearly.