iterator/property conflicts with table defaults

[kevinrr888]

Describe the bug
Background
#5990 fixed a bug where users could use NewTableConfiguration to attach an iterator or set a property that would conflict with table defaults (i.e., the default VersioningIterator at priority 20 for all iterator scopes, and the default table constraint (table.constraint.1 as DefaultKeySizeConstraint)).

For example, previously a user could attach an iterator (or manually set a property) through NewTableConfiguration to create another iterator at priority 20 leading to a table with 2 iterators at priority 20.
Another example, a user could set table.constraint.1 to some_constraint, leading to a table without DefaultKeySizeConstraint or without some_constraint (nondeterministic-which gets applied?)

The bug/what needs more investigation
There are other means of setting iterators. For example, setting a scan iterator with Scanner.addScanIterator or having an iterator or property inherited from the namespace level.

Need to investigate other means of setting iterators/props that would lead to conflicts with default iterators/props and fix any issues found.

Versions (OS, Maven, Java, and others, as appropriate):

• Affected version(s) of this project: 2.1+

To Reproduce
For checking scanner:
Create a table, create a scanner for that table, try to add an iterator to the scanner that would conflict with the default VersioningIterator, expect it to fail

For checking namespace:
Create a namespace with a property or iterator that conflicts with table defaults, create a table under that namespace, table creation should fail or potentially creating the namespace should fail

Expected behavior
Two iterators with same name or priority should not exist simultaneously
Need to prevent nondeterministic results of setting props