Summary:
The histogram types are defined in `Ticky.c` as `StgInt` values.

```
EXTERN StgInt RET_NEW_hst[TICKY_BIN_COUNT] INIT({0});
EXTERN StgInt RET_OLD_hst[TICKY_BIN_COUNT] INIT({0});
EXTERN StgInt RET_UNBOXED_TUP_hst[TICKY_BIN_COUNT] INIT({0});
```

which means they'll be `32-bits` on `x86` and `64-bits` on `x86_64`.

However the `bumpHistogram` in `StgCmmTicky` is incrementing them as if
they're a `cLong`. A long on Windows `x86_64` is `32-bit`.

As such when then value for the `_hst_1` is being set what it's actually doing
is setting the value of the high bits of the first entry.

This ends up giving us `0b‭100000000000000000000000000000000‬` or `4294967296`
as is displayed in the ticket on #8308.

Since `StgInt` is defined using the `WORD` size. Just use that directly in
`bumpHistogram`.

Also since `cLong` is no longer used after this commit it will also be dropped.

Test Plan: make TEST=T8308

Reviewers: mlen, jstolarek, bgamari, thomie, goldfire, simonmar, austin

Reviewed By: bgamari, thomie

Subscribers: #ghc_windows_task_force

Differential Revision: https://phabricator.haskell.org/D2318

GHC Trac Issues: #8308