Unbind references from container on scene unload

[villetuh]

Zenject doesn't properly clear reference from scene container when scene is unloaded. This results in memory leak when loading and unloading scenes.

Fixed the issue by unbinding all reference from scene container when SceneContext component is destroyed.

Thank you for sending a pull request! Please make sure you read the contribution guidelines

Pull request checklist

Please check if your PR fulfills the following requirements:

• [ ] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been reviewed and added / updated if needed (for bug fixes / features)
• [x] No compiler errors or warnings

Pull request type

Please check the type of change your PR introduces: - [x] Bugfix - [ ] Feature - [ ] Code style update (formatting, renaming) - [ ] Refactoring (no functional changes, no api changes) - [ ] Build related changes - [ ] Documentation content changes - [ ] Other (please describe): ## Issue Number

Issue Number: 246 in Zenject repository

https://github.com/modesttree/Zenject/issues/246

What is the current behavior?

• Currently it is possible that not all references are unbound when scene is unload. This can noticeable memory leaks depending on what has been referenced.

What is the new behavior?

• When SceneContext is destroyed all the bindings in its container are unbound. This ensures that no references are left hanging when SceneContext is no longer used.

Does this introduce a breaking change?

• [ ] Yes
• [x] No

Other information

-

On which Unity version has this been tested?

• [x] 2021.3 LTS
• [ ] 2020.4 LTS
• [ ] 2020.3
• [ ] 2020.2
• [ ] 2020.1
• [ ] 2019.4 LTS
• [ ] 2019.3
• [ ] 2019.2
• [ ] 2019.1
• [ ] 2018.4 LTS

Scripting backend:

• [x] Mono
• [x] IL2CPP

Note: Every pull request is tested on the Continuous Integration (CI) system to confirm that it works in Unity.

Ideally, the pull request will pass ("be green"). This means that all tests pass and there are no errors. However, it is not uncommon for the CI infrastructure itself to fail on specific platforms or for so-called "flaky" tests to fail ("be red"). Each CI failure must be manually inspected to determine the cause.

CI starts automatically when you open a pull request, but only Releasers/Collaborators can restart a CI run. If you believe CI is giving a false negative, ask a Releaser to restart the tests.