(wip) Update custom-dependency-inversion.md

[cabauman]

• Do not call InitializeSplat and InitializeReactiveUI because that will duplicate all Splat and ReactiveUI registrations.
• Add sample implementation of using FuncDependencyResolver with NInject
• Update implementation of IMutableDependencyResolver because two new interface members have been added.

I'm not familiar with Autofac, so I just put placeholders for the unregister methods. Can someone add implementations?

[glennawatson]

Autofac doesn't allow Unregister per say so it's fine to just leave the exception there. That was what I intended in containers where it wasn't supported.

[cabauman]

Thanks for clarifying @glennawatson

[RLittlesII]

I think this relates to #134
If our plan is to add an example per platform, I think we should have a main page that explains the concept and then individual pages where each container implementation is shown in isolation. We wouldn't want someone to copy and paste all of the code on the page, not realizing they are different implementations for different containers.

[RLittlesII]

Instead of calling this a bonus, which implies that it is an extra added bit to the auto fac code above. We should either move this to another page, or explicitly call out using a header tag that this is a different container.

[worldbeater]

Not sure, but maybe worth using the <details> tag to provide expand/collapse functionality for different ioc-container samples. In the beginning of the page we may describe what steps should a developer follow when creating a custom dependency resolver (implement IMutableDependencyResolver or use FuncDependencyResolver), and then show a list of collapsed buttons containing resolver implementations for most popular DI containers (Autofac, NInject, maybe SimpleInjector). The details-summary tags work like this, we use them in our getting-started guide:

<details>
  <summary>Expand-collapse title</summary>
  Collapsed content, can contain markup.
</details>

[RLittlesII]

Yeah. The suggestion for multiple pages is based on the current site paradigm and that it would make it easy to select a particular container if we explicity put it in their face. I am less concerned about how it is separated (pages, details, expanding buttons, hidden iframes), and more concerned about it being clearly marked that a specific code sample belongs to a specific container.

[glennawatson]

Once someone does reactiveui/splat#233 this documentation will change drastically, so could be worthwhile keeping it on one page.

[glennawatson]

Going to close this PR, thanks for the work @cabauman -- given now that @RLittlesII has put most of the major DI engines into Splat I don't think this one is as needed anymore.