AMR: make the octant coordinate integer type configurable per ForestBWG

`OctantBWG` stores its coordinates as `NTuple{dim, T}` with `T <: Integer`, so the
coordinate width is in principle a type parameter. In practice it is not: the
morton-index constructor hardcodes `Int32` for the step size,

```julia
# src/Adaptivity/BWG.jl
function OctantBWG(dim::Integer, l::T1, m::T2, b::T1 = DEFAULT_MAXLEVEL[dim]) where {T1 <: Integer, T2 <: Integer}
...
h = Int32(_compute_size(b, l))
```

so the width is fixed at this call site instead of following from the octant (or the
forest) it belongs to.

### Why this is worth fixing

- The coordinate type is currently decided in two unrelated places: `OctreeBWG{2,4}` /
`OctreeBWG{3,8}` construct with `Int64`, while this constructor produces `Int32`
intermediates. That is easy to get inconsistent and hard to reason about.
- Coordinate width is a real memory knob. Octant coordinates dominate the leaf arrays,
so `Int32` vs `Int64` is a measurable difference for large forests — but it should be
an explicit choice, not an accident of which constructor was called.
- A fixed `Int32` is an obstacle for backends that want a specific width (e.g. GPU).

### Proposal

Define the octant type once per `ForestBWG` instance — i.e. carry the coordinate integer
type as a parameter of the forest/tree and derive `h` (and the other integer temporaries)
from it, rather than hardcoding `Int32`.

Note that `DEFAULT_MAXLEVEL = (0, 30, 19)` inherits p4est's `P4EST_MAXLEVEL` /
`P8EST_MAXLEVEL`, which exist precisely because p4est stores coordinates in 32 bits. If
the width becomes configurable, the admissible maximum level should follow from it
instead of being a hardcoded constant.