Rename "stream" to "channel" in the UI

[gnprice]

This is the zulip-flutter counterpart of:

• Use "stream" or "channel" based on server version zulip-mobile#5827
• Rename "stream" to "channel" zulip#28468

Unlike in zulip-mobile, in zulip-flutter let's do this unconditionally: we'll refer to a channel as a "channel" even on older servers where the web UI says "stream". By the time we roll out zulip-flutter to general users some months from now, it'll have been "channel" on Zulip Cloud and in the latest server release for at least a few months, so probably a relatively small fraction of users will be on older servers that use the old terminology, and it's OK if they see the new terminology in their mobile app.

(When we add wildcard mentions #234, those will need to condition on the server version, because it's a correctness issue: sending @**channel** to an older server just won't work. (I'll update #234 to note that.) But that's a lot more localized.)

This issue is purely about the user-facing strings: everywhere we say "stream" to the user, we should say "channel" instead. I'll file a follow-up issue for renaming identifiers in our codebase.

[Khader-1]

Additionally, we have some strings that are not user-facing yet they're not identifiers (Test names / descriptions, comments etc) Some of them might become irrelevant when updating user-facing strings.

Should those be targeted in this issue? or should we target them in #631?

[gnprice]

Good question. Let's have a PR for this issue that's focused purely on updating what the user sees — that will help keep down the complexity so we can finish and merge that PR quickly and include it in a release as soon as possible. (We make releases of this app every couple of weeks.)

Then for all kinds of updates that don't have any effect on the app's behavior, we do want to get those done (in order to have this migration complete and stop having two names to think about), but there isn't the same urgency because users don't see it, and in particular it doesn't matter at all whether those changes make it into a given release. So we'll handle those all as part of #631, and it's fine if that happens a week or two later.