bug(configtxgen): fragile panic recovery using string matching instead of proper error handling

# Description
The `configtxgen` utility relies on extremely brittle string matching during panic recovery to handle configuration loading errors. If upstream dependencies change their panic formats, it can lead to unhandled panics and silent failures.

## Details
In `configtxgen/main.go` (around lines 61-77), a deferred `recover()` catches panics from `configtxgen.Load()`. It currently uses `strings.Contains(fmt.Sprint(err), "Error reading configuration: Unsupported Config Type")` to determine the error type.

This approach is highly fragile for two reasons:
- If the upstream library changes its panic message format, the string match will silently fail and re-panic with `logger.Panic(err)` instead of displaying the intended, helpful error message to the user.
- The control flow relies heavily on panic/recover semantics rather than standard Go error returns.

## Expected Behavior
Errors encountered during `configtxgen.Load()` should be handled using standard typed errors rather than string-matching against a panic payload.

## Proposed Solution
- Wrap the `configtxgen.Load()` calls in a helper function that safely recovers panics and converts them to typed Go errors.
- Replace the string matching (`strings.Contains`) with proper error type checks such as `errors.Is` or `errors.As`.
- Add comprehensive unit tests to ensure error handling behaves correctly even if upstream messages change.