`wp_term_insert` inconsistent validation logic for `name` and `slug`

[xipasduarte]

Right now the way a term is inserted is inconsistent with cases that render the same ($name, $slug) pair as either an error or a success.

Considerations
Inferred from the code logic:

• The $name is treated as a sort of logically enforced primary key
• The $slug is enforced as unique

Inconsistencies
The following examples are only indicated as ($name, $slug) pairs for simplicity, but they represent wp_insert_term operations.

('A', 'a') // Success
('A', null) // Error: term name exists
('A', 'a') // Success (term slug is changed to "a-2")

Exploring a little more on the second insert we can have the following.

('A', 'b') // Success
('A', null) // Error: term name exists
('A', 'a') // Success (no term slug change)

Documentation
In the documentation it is stated that:

If the term already exists on the same hierarchical level, or the term slug and name are not unique, a WP_Error object will be returned.

The documentation is not clear on what "exists" means in the context of hierarchical terms, but it indicates that the pair ($name, $slug) should be the logically enforced primary key. If this is the case, which is not apparent from the code, than the same issues apply, although a different solution is required.

Proposal
Considering what a term is, a relationship (see ​https://wordpress.org/documentation/article/taxonomies/):

1. always return WP_Error( 'duplicate name' ) when the $name is a duplicate (inside the same hierarchical level), preventing duplicate visual references. (Example: A term "Vegetarian" with $slug = 'vegetarian' would be indistinguishable from another "Vegetarian" with $slug = 'vegetarian-2'.)
2. make the ('A', null) examples behave as ('A', 'a').

[xipasduarte]

Changes for proposal 1

[xipasduarte]

Changes for proposal 2

[xipasduarte]

Still need to run and review tests, but the diffs should be enough for quick check of the changes.