Align conflicts checks with reality

[se]

Summary

The conflicts change historically treated packages from the same origin as generally non-conflicting.
The reason might have been that packages built from the same origin for different FLAVORs might have matching package names, but might be able to co-exist.

There have been 2 changes that cause issues due to this assumption:

1. FLAVORS lead to conflicting packages that can not co-exist, e.g. "git" and "git-lite".
2. Package names have been made unique for each FLAVOR.

As a result, the same origin exception from the conflicts tests voids CONFLICTS definitions in a port's Makefile with conflicting FLAVORs.
E.g. devel/git has a CONFLICTS definition that excludes all other FLAVORS, but the conflict is not reported due to the same origin exception.

Test Plan

Test whether a conflict is detected when building and installing git-lite from a port on a system with git installed (with default FLAVOR).
Execute "make -V CONFLICTS_INSTALL" and "make check-conflicts FLAVOR=lite" - while the former lists "git" as conflicting, the latter does not generate any output.
The build will succeed, but the installation will fail due to an existing git program that would be overwritten.

With the patch applied, the CONFLICTS entry in the Makefile allows to identify the conflict before building the port.
This is a mechanism that is used by port management programs like portmaster to identify and resolve conflicts (e.g. if a port depends on git-lite to not try to overwrite an installed git).
This causes issues as e.g. reported in PR 250335.

[adamw]

IIUC, the nature of the origin exclusion prevents using CONFLICTS_INSTALL for flavored ports. This definitely sounds problematic to me. And if so, none of my vim ports will properly conflict. Can someone please take a look at this review? It seems like a problem worth fixing.