[doc] update iOS app tutorial

[aaronsky]

• remove mentions of WORKSPACE
• polish up the blocking, wording for consistency
• update language around rules_xcodeproj

Fixes #2737

[mattrobmattrob]

Thanks for cleaning that up. Mostly nits that we can take or leave. Mostly just like retaining the same BUILD vs. BUILD.bazel that's convention in rules_apple and rules_xcodeproj.

[aaronsky]

@mattrobmattrob thanks for the review. I was drawing from the note here about which takes precedence, and the general trend of the rest of the ecosystem towards naming build files with the extension. I don't know if there's any other reasons to choose one over the other.

[mattrobmattrob]

My tool stack (VS Code) uses .bazel as one of the triggers to assume Starlark parsing but I don't care, really. Just nice that this doc matches the referenced examples, IMO.

[aaronsky]

@brentleyjones do you know why rules_apple/swift/xcodeproj + apple_support all use BUILD? Is it to make cherry-picking upstream easier or some other style reason? and do you have an opinion about this? (if not it's okay)

[mattrobmattrob]

AFAIK it's just historical but cherry-picking seems like the best argument to not mess with it (in rules_apple, anyway).

[brentleyjones]

AFAIK .bazel is mainly as a backup in case you can't name it just BUILD, because you already have a build folder. Most tools know to look for BUILD in addition to *.bazel for Starlark.