Fix optimizer parameter types

[Irozuku]

This pull request refactors both backend and frontend handling of hyperparameter optimization (HPO) for integer and float/number parameters. The changes standardize how parameter types are tracked and passed through the optimization pipeline, ensuring consistent behavior and cleaner code. On the frontend, the input components for integer and number optimization have been updated to better merge user data with defaults, improve state management, and clarify UI behavior.

Backend: Improved parameter type tracking and usage

• The optimizer schema field functions now return Python types (float for optimizer_float_field, int for optimizer_int_field) instead of dicts, aligning with their intended usage.
• The model factory now extracts the parameter type from the component schema and passes it through the optimization pipeline, allowing downstream optimizers to use explicit type information instead of relying on value inspection.
• Optimizer implementations (base_optimizer.py, hyperopt_optimizer.py, optuna_optimizer.py) now use the parameter type field ("integer" or "number") to select the correct distribution or suggestion method, improving reliability and maintainability.

Frontend: Improved integer and number input components

• The OptimizeIntegerInput and OptimizeNumberInput components now merge user-provided values with placeholder defaults more robustly, ensuring the UI always reflects the latest state and defaults. They also use local state for immediate UI feedback and properly handle nulls and type conversions.
• UI labels and error handling have been improved for clarity, and the components now conditionally render optimization controls and bounds based on parameter capabilities. Prop types and default props have been updated for better flexibility and validation.

Other improvements

• Minor code cleanups and error handling improvements, such as moving the evaluator instantiation in importance_plot into a try block.