Add deprecation warnings for package-internal APIs

[rebello95]

This PR adds deprecation warnings to APIs that are considered package-internal but cannot yet be marked as package instead of public until we adopt Swift 6 (see #310). We can't make these APIs currently deprecated since that will introduce deprecation warnings where they're used within the library, but we can at least add future deprecation warnings which will show up in the IDE as shown below:

The goal of doing this is to help enable us to tag a 1.0 before adopting Swift 6 so we can mark those APIs as package afterwards and reasonably consider it a non-breaking change.

[jhump]

This could be misleading. Is it dangerous to use 1.1 instead? If we end up needing a minor release before we're actually ready to use Swift 6 package visibility, could we just bump this out to 1.2? Would that cause havoc?

[rebello95]

This refers to the version of Swift that this will be deprecated in - it's just an arbitrarily high number which doesn't show up in the warning message. Unfortunately, we cannot specify which version of the package something will be deprecated in as part of this macro

[jhump]

Oh. So why not set it to 6?

[rebello95]

I tested this out, but it triggers warnings if a consuming project upgrades their Package.swift to use Swift 6, which we don't want:

[jhump]

Per separate chat, let's also rename these to start with an underscore -- yet another convention to indicate the symbol is private and that users should avoid it. That way we should be comfortable that a future release that makes them inaccessible will not break anyone.

Otherwise, LGTM.

[rebello95]

Per separate chat, let's also rename these to start with an underscore -- yet another convention to indicate the symbol is private and that users should avoid it. That way we should be comfortable that a future release that makes them inaccessible will not break anyone.

Updated to prefix with underscores 👍🏽