No pressure, but here's some info:
Weapons have a MinX, MaxX, MinY and MaxY angle. A weapon pointing straight forward is at angle 0, 0. Values are currently in degrees, where the min is a negative and max is positive angle. X is up (min) and down (max). Y is left (min) and right (max).
Imagine that == is a cannon facing to the right on the page
Weapons also have a bool flag for whether Y-axis rotation is limited at all. The large cannon has unlimited Y rotation (Y min/max are just ignored) unless it's blocked by something.
X-axis (up/down) rotation is currently limited to not more than 90 degrees each way (180 total). Y-axis (left/right) rotation can also be assumed to be <= 180 each way. This might make calculations simpler.
Y is up in Unity. Z is forward.
The weapon's range needs to be checked against colliders on the vehicle.
They're all un-rotated boxes (they're actually rotated in multiples of 90 degrees, but a box rotated 90 degrees is still an un-rotated box). So they can be checked with a simple AABB collision check or a raycast can check for a collision with them.
Note that although parts are generally snapping to a grid, colliders aren't in any sort of grid pattern - they're just located wherever they're needed to cover the part models. In practice I found that a raycast method was never accurate enough to get things right every time (unless the raycasts were made very closely-spaced, but performance is important here too).
Each part has a collider that just covers the whole part, on top of the more specific colliders that cover it more accurately. This can be used as an early check: If the encapsulating collider isn't hit, none of the inner ones will be. If it is hit, we can look more closely.
Part colliders are also inside an octree, so you can so fast collision checks on a specific area if necessary. Currently it accepts AABB bounds and returns all colliders that intersect those bounds. Alternatively if you need to check every collider, you can just run through an array of them all.