Issue title: Constraint.cs visibility
 Issue body: Should this class be used as base to create custom constraints?
If so, why there many methods/properties marked as internal that are actually needed to implement a new constraint.
Well, in my opinion if this class is not to be used in external code it should also be marked as internal, so external developers are not confused by it.
Thanks.

 Comments: 
 Comment 0: Are you referring to System.Data.Constraint?
https://docs.microsoft.com/en-us/dotnet/api/system.data.constraint?view=netcore-2.1

https://social.msdn.microsoft.com/Forums/en-US/e94dbfe1-d076-4ffa-8bbe-2e47d8b83453/dataset-adding-custom-constraints
 Comment 1: Exactly this one!
I did look at these links, not very helpful...
I understand that this class is used to generalize constraints in the DataTable's constraints collection, but as you are exposing it to outside code, shouldn't it be fully usable?
If not shouldn't it expose an interface with just the generalization to work with the constraints collection?
The question here is, why is the class abstract, externally exposed, and not usable?
 Comment 2: > The question here is, why is the class abstract, externally exposed, and not usable?

I didn't design or implement this class.  But...

It's exposed because derived types UniqueConstraint and ForeignKeyConstraint are exposed, and because APIs then work in terms of the base to support either, e.g. DataTable.Constraints.

It's abstract because you're not supposed to instantiate one of these directly, only the derived types, and making it abstract is one way to do that.

I don't know what you mean about it not being usable.  If you mean not extensible by code external to the assembly, then because it wasn't designed for that.  Not every type that's extended internally needs to support the same level of extensibility externally.  And while you might want that, that would be a separate feature.

This type has been this way for many, many .NET releases.
 Comment 3: Thanks Stephen for your insights!
I'm sure that this is not a good design, and don't believe that something being in place for long time makes it good, you just get used to it.
More over, that is not the intended usage of abstract classes, interfaces serve this purpose, abstract classes have a inherent behavior that child classes must respect.
I still believe that the Constraint class should be exposed as an public interface and the abstract class moved to be internal to the assembly.
 Comment 4: > I still believe that the Constraint class should be exposed as an public interface and the abstract class moved to be internal to the assembly.

That would be a big breaking change and is not going to happen.  That was part of what I meant to imply by my "this type has been this way for many, many .NET releases" comment, not that "being in place for long time makes it good."

If you want to propose and detail an additional extensibility mechanism, you're welcome to do so in a separate issue.

For now, I'll consider the question answer.  Thanks for the interest.
{'source': 'GithubIssues', 'repo_name_with_owner': 'dotnet/corefx', 'issue_id': 369094623, 'repo_stars': 20466.0}