Pre-RFC: `pub(api)` visibility, and static enforcement of crate-internal API boundaries

It shouldn't block pub(api) because, as mentioned, it would become a weak keyword. The set of possible first tokens in a pub(E) context I believe are self, super, and in otherwise. If that is the case, then introducing api as another should not be ambiguous.

While pub can be used within a module, the rustc lints documentation suggests that the only reason this isn't a default warning is that it would break too much code right now, and may change. See my reply to @robofinch about unreachable_pub.

I'm perfectly happy with replacing #![api] with another way of definining the boundary. I provide some alternatives I came up with off the top of my head in the RFC. While it may be possible to import a module as the name api, note that this is unrelated to my suggestion, as the pub(api) visibility modifier is not using api as a name in the current module scope. There are several potential benefits to having an alternate visibility, such as ensuring that non pub(api) items don't escape a module boundary, and to allow for the visibility of an API boundary module and its exported items to be modified with a single visibility at the module definition site.