feat(BitField): add problematic bit to error

[almostSouji]

Please describe the changes this PR makes and why it should be merged:

Provide the offending bitflag to the BITFIELD_INVALID error for easier debugging

Status

• Code changes have been tested against the Discord API, or there are no code changes
• I know how to update typings and have done so, or typings don't need updating

Semantic versioning classification:

• This PR changes the library's interface (methods or parameters added)
  • This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
• This PR only includes non-code changes, like changes to documentation, README, etc.

[almostSouji]

Switched to a different approach to avoid semver major

[papaia]

This is still undocumented and un-typed.

[kyranet]

I think it might be worth to mention that this RangeError has an extra property of bit, but otherwise LGTM.

[almostSouji]

I really think documenting this is out of the scope of what a minor can do. Yes, we could put a note in the #resolve jsdocs, though I really don't see much benefit in that, seeing that the only purpose of this method is to internally validate bit flags. If they know of resolve they're likely reading source code anyways and will see the bit property.

The more surfacing approach would be to bubble the documentation to the methods users might actually use, however that's 1) a lot and 2) would be rather inconsistent with other parts of our documentation where we choose to not overload jsdocs with a bunch of notes.

I can not find any way to document or type this in a way so it may be useful for the user.

As is proposed this will serve as additional hint for both our support flow (not having to read a ton of code in order to find the offending flag name) as well as users that properly handle their promise rejections and log full errors.