Make ambiguous mark attachment a WARNING instead of INFO

[belluzj]

As previously discussed in PR #416, the log message when a base and mark can attach through several pairs of anchors (thus an "ambiguous" pair) is INFO. But since that PR I've seen several projects at Dalton Maag where people create this confusing situation and don't realize that this is the source of the issue. I think in most cases, such ambiguity is a sign of confusion on the designer's side and should be flagged at a higher log level.

If not, could designers who actively rely on this ambiguity chime in to explain what is their use-case? @khaledhosny was one such designer who wanted the situation and no warnings about it.

I'm ok to demote the logging message to an INFO level and simply inform about the potential ambiguity. We can document that the multiple markPos lookups will follow a predefined order (alphabetic + special case for legacy bottom/top anchors).

Originally posted by @anthrotype in https://github.com/googlefonts/ufo2ft/issues/416#issuecomment-728267870

[khaledhosny]

I have base glyphs with both top and top.alt anchors while other base glyphs has only top anchors, and mark glyphs with either both _top and _top.alt or only _top anchors. This way if base has top.alt and mark has _top.alt that attachment will be used for this glyph pair, otherwise it will fallback to top attachment.

[khaledhosny]

I actually find INFO here to be a bit too much, this is more of a DEBUG message, but I almost always use fontmake with WARNING log level because otherwise it is too verbose so it doesn’t bother me much.

[behdad]

Having read the discussion in the referenced issue and here, I suggest this: if a mark can be attached via multiple anchors, then for any two such anchors a and b, (eg a = 'top' and b = 'top.alt'), then if b.startswith(a) and len(b) > len(a) + 1 and not b[len(a)].isalnum() remove a from the candidates.

If more than one anchor is left, warn. Output anchors in alphanumeric sorted order.