Rewrite SMO collections using generics

[shueybubbles]

Our collection classes are based on .Net 2.0 technology and are very out of date.
We should replace as much functionality as possible with reflection-free code and implement standard generic collection interfaces like IList<T> instead of requiring apps to cast.

[shueybubbles]

bonus points for writing a C# source generator to create the collections instead of our custom templates.

[Matteo-T]

bonus points for writing a C# source generator to create the collections instead of our custom templates.

I've always wanted to do that. You are bad influence!!!

[aguzev]

Training a neural net is trendy this year.

[shueybubbles]

Notes on current research:

• We can put enough logic into the base classes to justify removal of the codegen for collections altogether.
• We can remove one use of reflection to invoke the internal constructors of SqlSmoObject derived types by putting a factory method on each collection class.
  eg:

public interface ISmoObjectFactory<T> where T:SqlSmoObject
{
  T NewObject(ObjectKeyBase key, SqlSmoState state);
}

public class TableCollection : SchemaCollectionBase<Table, Database>
{
...
  public Table NewObject(ObjectKeyBase key, SqlSmoState state) => new Table(this, key, state);
...
}

• To eliminate the use of reflection to find collection class constructors, we'll probably need a C# source generator to find all the concrete implementations of AbstractCollectionBase and generate a function whose body is just a big lookup table of `[Urn type, Parent class name] tuples to call the appropriate collection constructor.

[shueybubbles]

Here's a potential new implementation of AlertCategoryCollection if we genericize the base classes:

using Microsoft.SqlServer.Management.Sdk.Sfc;

namespace Microsoft.SqlServer.Management.Smo.Agent
{

    ///<summary>
    /// A collection of AlertCategory objects associated with a JobServer
    ///</summary>
    public sealed class AlertCategoryCollection : SimpleObjectCollectionBase<AlertCategory, JobServer>
    {
        /// <summary>
        /// Constructor needed for use by reflection.
        /// </summary>
        /// <param name="parentInstance"></param>
        internal AlertCategoryCollection(SqlSmoObject parentInstance) : base((JobServer)parentInstance)
        {
        }

        protected override string UrnSuffix => AlertCategory.UrnSuffix;

        internal override AlertCategory GetCollectionElementInstance(ObjectKeyBase key, SqlSmoState state) => new AlertCategory(this, key, state);

    }
}

We can remove the need for collection codegen because Visual Studio will essentially write the code for you once you declare the base class.

[shueybubbles]

...only 127 more collections to update

[shueybubbles]

BTW I am delaying IList<T> simply because there are some requirements about forcing initialization of the collection before enumeration that are not obvious how to reconcile with this interface just yet.