[crossdriver] Adjust type declarations around chanspecs to match usage

There was a dormant bug where a chanspec was truncated to a `uint8_t`
when chanspecs are generally `uint16_t`. This change is contains fixes
for additional typing nits around chanspec code.

crossdriver/brcmwifi_channels.cc

- `chanspec_t` is an alias for `uint16_t`. The former should be
  preferred in contexts where a chanspec is assigned.
- `CHSPEC_CHANNEL` casts the result to a `uint8_t`, so the swap
  of `chspec_ch` from `uint16_t` reflects its "actual
  type". Additionally, the `MAXCHANNEL` constant that `chspec_ch` is
  compared to is defined as `224`. Finally, 802.11 channel numbers
  must fit in a single byte anyway, and the cast in `CHSPEC_CHANNEL` is
  a reflection of that.
- Declaring `bw_mhz` as `uint32_t` instead of `uint8_t` will prevent
  unintentional truncation when we support 320 MHz. Additionally, the
  `channel_to_sb` that that variable is passed to accepts a `bw_mhz`
  with `uint32_t`.
- Declaring `sb` as an `int16_t` instead of `int32_t` is a no-op because
  the only assignment where it's swapped is from the `channel_to_sb`
  function that returns `int16_t`.

crossdriver/dhd.cc

- Declaring `band` as `chanspec_t` ensures its type is consistent with
  the assignment from a masked `chanspec_t`. `int` is 64-bit and
  `chanspec_t` is 16-bit, so this swap is a no-op.

Bug: 541960583
Change-Id: I7ddc444ad0d0cef88a60e62ea4a635f68a4acdc2
Reviewed-on: https://fuchsia-review.googlesource.com/c/third_party/bcmdhd/+/1739469
Reviewed-by: Bjoern Johansson <bjoernj@google.com>