iterator/property conflicts with table defaults

**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