fix: Implement migration adapter check for textual settings parameters.

[prmukherj]

This change updates the type-checking logic to correctly handle cases where a migration adapter is present.

Previous Behavior

When setting a textual attribute through PyFluent, type checking was performed before delegating to the underlying Settings API.
If the provided value did not strictly match the expected type, PyFluent raised a TypeError, even in cases where a migration adapter existed to handle type conversion.

For example:

>>> solver.settings.setup.models.discrete_phase.general_settings.unsteady_tracking.create_particles_at = False

Here, the property accepts a string value, but a migration adapter is available that correctly converts a boolean (False) into the appropriate string value.
Previously, PyFluent would still raise a TypeError before this conversion could occur.

Current Behavior

If a migration adapter exists for a setting, PyFluent now bypasses type checking and directly forwards the input to the Settings API.
This allows the migration adapter to handle type conversions or other logic as intended.

Please refer to the test to see the detailed usage.

The change aligns PyFluent behavior with the Fluent-side fix (ref. bug 1293534).

[seanpearsonuk]

The description!

[prmukherj]

The description!

Done, Thank you

[mkundu1]

@prmukherj Can you please add a test?

[prmukherj]

@prmukherj Can you please add a test?

yes, sure, will add one before merging. Thank you for mentioning it.

[prmukherj]

@prmukherj Can you please add a test?

yes, sure, will add one before merging. Thank you for mentioning it.

@mkundu1, added the test mentioned in the fluent bug with a different case file.

[seanpearsonuk]

Reading the description, it’s hard to tell which parts describe the current behavior and which describe the changes introduced in this PR.

This is a wider issue for us: our PR descriptions often don’t make it easy to reconstruct what changed and why. Ideally, we should aim for descriptions that make sense even years later when reading the commit history.

At the moment, we’re falling short of that goal, and this PR is a good example of where we could do better.

[prmukherj]

Reading the description, it’s hard to tell which parts describe the current behavior and which describe the changes introduced in this PR.

This is a wider issue for us: our PR descriptions often don’t make it easy to reconstruct what changed and why. Ideally, we should aim for descriptions that make sense even years later when reading the commit history.

At the moment, we’re falling short of that goal, and this PR is a good example of where we could do better.

@seanpearsonuk, could you please have a look if it is better now?