make it able to use external UI dlls without referencing UnityWeld

[TimGameDev]

Main goal: make it able to use external dlls which contains abstract UI logic without referencing UnityWeld.
Benefits:

• no tight coupling with UnityWeld
• external dlls keep its abstraction level and can be used as you want (i.e. in console application or whatever)

This is very good practice and should be done in every such plugin. For example Zenject has it by default.

Done:

• registration of custom Binding attribute (default one is preregistered)
• registration of custom ViewModelProvider (default one is preregistered)

/How to use (just an example)/
Create Unity script with the following (You don't need to create anything if you use default binding attribute and view model provider)

#if UNITY_EDITOR
    [UnityEditor.InitializeOnLoad]
#endif
    public static class UnityWeldIoC
    {
#if UNITY_EDITOR
        static UnityWeldIoC()
        {
            Register();
        }
#endif

        private static void Register()
        {
            TypeResolver.RegisterCustomBindingAttribute<BindingAttribute>();
            TypeResolver.RegisterCustomViewModelProvider(ViewModelProvider);
        }

        private static ViewModelProviderData ViewModelProvider(Component component)
        {
            if (component is IViewModelProvider provider)
            {
                return new ViewModelProviderData(provider.GetViewModel(), provider.GetViewModelTypeName());
            }

            return null;
        }

#if !UNITY_EDITOR
        [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
        static void Initialize()
        {
            Register();
        }
#endif
    }

[RoryDungan]

Overall looks like good code and a useful addition, thanks! There are a couple of minor things I think could be tweaked but the main blocker is that not ready to drop .NET 3.5 support just yet. See issue #36 for discussion about the .NET 3.5 issue.

[RoryDungan]

Why does this and ViewModelProviders both have a size of 2 but only one element? Since most users aren't going to register a custom binding attribute I'd rather just have this default to one, and afaik adding an element to a .NET list is very cheap.

[TimGameDev]

The thought process is to avoid additional allocations after start. And since in most cases we need list with size of 2 (max, default and custom) I've decided to use this number as initial capacity.
But I missed the fact that it happens only during initialization phase.
However I wouldn't use default capacity, it will be 3 useless refs in memory during whole app life time, unacceptable! :)
What do you think?

[RoryDungan]

Since we want RegisterCustomBindingAttribute and RegisterCustomViewModelProvider to be used externally, it would make more sense to either move this class out of the UnityWeld.Binding.Internal namespace or move those functions to a separate class outside that namespace. It occurs to me now that everything inside the UnityWeld.Binding.Internal namespace should probably also use the internal access modifier instead of public but that's not in the scope of this PR so don't worry about changing that.

[TimGameDev]

I agree. Was confused by public access of this class.
But I'm not totally sure what the best way to do this...
In my opinion this is strongly relate to IoC principle, so I think I'll made class like "TypeRegistry" inside IoC namespace. And TypeResolver will use public properties of this class.

pseudo:
class TypeRegistry
BindingAttributeTypes { get; }
ViewModelProviders { get; }

RegisterCustomBindingAttribute()
RegisterCustomViewModelProvider()

Do you agree?

[RoryDungan]

I'd prefer not to change from string.Format to string interpolation since it will break the code in older versions of Unity, although I guess if this PR still requires .NET 4.x support then I think all versions of Unity that support that should work with this as well. In general I'd prefer not to change stuff like this unless necessary though.

[RoryDungan]

Can you please revert all the formatting changes in this and other files? I know it's a bit of a nitpick but there are a few things in your PR that break from the convention that's used throughout the rest of the codebase:

• There should always be a space before the opening ( after an if, while, using, do, or for statement, e.g. if (SomeExpression())
• When breaking a long statement onto multiple lines, only indent one level - don't indent to make the code line up with something on the previous line. When breaking a function call onto multiple lines, the closing bracket should always be on the same indent level as the opening bracket, and if there are multiple arguments each argument should be on a separate line:

// Do this:
var monoBehaviourViewModel = cache.Components
    .FirstOrDefault(component =>
        component.GetType().ToString() == viewModelName
    );

var providedViewModel = cache.Components
    .Select(component => component.GetViewModelData())
    .Where(component => component != null)
    .FirstOrDefault(
    // etc...

[RoryDungan]

Is this cache system necessary for the original purpose of making Unity Weld more decoupled from UI code? It looks like a separate feature to me but could maybe still be a useful addition. Could you explain a bit more about how it works?