Fix #7 by refactoring startup.py

[danbradham]

Rather than setting BLENDER_USER_SCRIPTS in startup.py, this PR copies Shotgun_menu.py file to a users existing BLENDER_USER_SCRIPTS/startup directory. This allows users to continue using their existing BLENDER_USER_SCRIPTS directory to install custom addons and modules as they need them.

For our studio we already were setting BLENDER_USER_SCRIPTS to a shared network path, so this PR allows us to continue doing that. I'm hoping one day Blender will allow multiple paths to be set but for now this is the best alternative I could come up with.

[MoisMoshev]

I think this change is beneficial because it allows more complex setups. We also prefer to manage our addons separately from the engine. That said, it has its downsides, because copying files is slower, less reliable, etc. than setting a variable. Just something to keep in mind.

Re the last sentence: Houdini is something to learn from when it comes to configuration options.

[danbradham]

Absolutely @MoisMoshev.

To try to make this as robust as possible I'm doing two important things during prepare_launch.

1. Using bpy.utils.script_path_user() to ensure that Shotgun_menu.py is copied to the correct user scripts directory.
2. Replacing Shotgun_menu.py if it already exists and the file in tk-blender engine is newer.

I forgot to mention that this is still a work in progress. I'm modifying Shotgun_menu.py to only register when launching via Shotgun. I.E. when the appropriate context and engine variables are present in os.environ.

[danbradham]

Added some logic to Shotgun_menu.py to prevent the Shotgun menu from presenting when tk-blender engine is unavailable.

If you get a chance test this PR using this engine location and let me know what you think.

engines.tk-blender.location:
  type: git
  path: https://github.com/danbradham/tk-blender
  version: 4698fef

[francoisgfx]

I would love to see this merged in the next release. Redefining the BLENDER_USER_SCRIPTS is too rigid for us as well