[Chapel Merge] Respect privacy and limitations of use and import

Branch: refs/heads/master
Revision: 03cf9d9
Author: lydia-duncan
Log Message:

Merge pull request #16712 from lydia-duncan/respectPrivateAgain3

Respect privacy and limitations of use and import statements when resolving methods
[reviewed by @mppf]

Removes the support for ignoring the privacy and limitations of use and import statements
when resolving methods. While the implementation is slightly more complex as a result, it
simplifies the explanation of when symbols can and cannot be found.

Resolves Cray/chapel-private#1423

Updates a comment to reflect the new behavior.

Makes getVisibleMethodsImpl pay attention to whether a scope has been entered through
a use/import chain or by traversing upwards from the call site. This allows us to distinguish
between private uses that we should follow (because we are in the scope where they occur)
and private uses that we should ignore. Pulls the act of checking the symbols defined
directly in a scope into a helper function, as well as traversing the use list.

Adjusts lookAtTypeFirst to also jump to the point where a parent type was defined. The
traversal of private uses had allowed us to find inherited methods, but we need to explicitly
jump to those scopes now that such uses are respected. Also track whether the scope we
jump to is the same as the scope we are currently in - if not, we should respect the privacy
of any use and import statements we find while there.

Remove isScopeVisibleForMethods and its helper map. We can now rely on normal visibility
computation.

A couple of modules needed updates for this new behavior - BlockDist and StencilDist were
relying on the cast function for c_void_ptr just being visible and now explicitly use CPtr
(where it is defined), and the TOML module now has a use of IO in order to access the format
method on strings.

Testing