Reject unsupported `ORDER` values explicitly instead of panicking later with arithmetic overflow

The crate currently has implicit constraints on the const generic ORDER, but those constraints are not checked explicitly.

What I can reproduce today:

• FrameAllocator::<0> panics later due to ORDER - 1
• Heap::<0> also panics later due to ORDER - 1
• FrameAllocator::<{ usize::BITS as usize + 1 }> panics later due to shift overflow

Relevant code:

• src/frame.rs:58 -> 1 << (ORDER - 1)
• src/lib.rs:106 -> if order > ORDER - 1

Reproduction

use buddy_system_allocator::{FrameAllocator, Heap};

#[test]
#[should_panic]
fn frame_allocator_order_zero_panics_late_with_underflow() {
    let mut frame = FrameAllocator::<0>::new();
    frame.add_frame(0, 1);
}

#[test]
#[should_panic]
fn heap_order_zero_panics_late_with_underflow() {
    let mut heap = Heap::<0>::new();
    let mut space = [0usize; 1];

    unsafe {
        heap.add_to_heap(
            space.as_mut_ptr() as usize,
            space.as_mut_ptr().add(1) as usize,
        );
    }
}

#[test]
#[should_panic]
fn frame_allocator_order_above_usize_bits_panics_with_shift_overflow() {
    let mut frame = FrameAllocator::<{ usize::BITS as usize + 1 }>::new();
    frame.add_frame(0, 1);
}

Why this matters

Today, invalid ORDER values are accepted at construction time and only fail later during normal allocator operations.

That makes the failure mode harder to understand:

• the panic happens far away from the actual configuration mistake
• the panic message reports arithmetic overflow instead of an invalid type parameter
• users have to reverse-engineer the real precondition from implementation details

Suggested fix

At minimum, reject unsupported ORDER values explicitly in constructors:

• FrameAllocator::new() should reject ORDER == 0
• Heap::new() should reject ORDER == 0
• FrameAllocator::new() should also reject ORDER > usize::BITS as usize

If maintainers prefer a uniform crate-wide rule, the same upper bound could also be applied to Heap.

A runtime assert! in new() is probably the smallest change, though a const assertion would also work if a compile-time failure is preferred.

If it is confirmed to be a bug, I can submit a PR to help fix it.

Start with the constructor paths for FrameAllocator and Heap, then inspect src/frame.rs:58 and src/lib.rs:106 to understand the unchecked ORDER assumptions. Run the supplied reproduction tests and add coverage for invalid ORDER values; done means unsupported values are rejected at construction instead of failing later with arithmetic overflow.