Default scaler objects for properties and reactions

[dallan-keylogic]

Fixes

• Getting default scaler and default initializer broken for scaler state blocks #1686
• Item 5 of Outstanding issues with the new scaling tools #1648

Summary/Motivation:

When using the old scaling tools, we could set default scaling factors to use for all state blocks using a property package. With the new scaling tools, heretofore we have been forced to use changing the class attribute DEFAULT_SCALING_FACTORS. Global mutation is dangerous and ought be avoided when possible.

In this PR, I allow the user to specify a default scaler object to use for all instances of a property or reaction package in a flowsheet by setting the default_state_scaler_object or default_reaction_scaler_object on their respective parameter blocks.

Additionally, I fixed the issue with the default scaler object for scaler state and reaction blocks.

Legal Acknowledgement

By contributing to this software project, I agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the license terms described in the LICENSE.txt file at the top level of this directory.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[MarcusHolly]

LGTM

[codecov]

Codecov Report

❌ Patch coverage is 70.17544% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.81%. Comparing base (6258f28) to head (ca73fd7).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
idaes/core/base/property_base.py	61.90%	8 Missing ⚠️
idaes/core/base/reaction_base.py	61.90%	8 Missing ⚠️
idaes/core/scaling/custom_scaler_base.py	93.33%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1766      +/-   ##
==========================================
- Coverage   73.83%   73.81%   -0.02%     
==========================================
  Files         419      419              
  Lines       66225    66274      +49     
  Branches    11122    11133      +11     
==========================================
+ Hits        48894    48919      +25     
- Misses      14794    14814      +20     
- Partials     2537     2541       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bpaul4]

Does that mean we know that this will never happen? In that case we should preempt the default error with our own, or remove the error since it is never happening anyways. Same with other ones in this PR, and I think that will help you on code coverage as well.

[dallan-keylogic]

No. What happens is that, if this error is triggered, either Python or the create-on-demand property framework will intercept this error in a try block, then raise its own AttributeError. I thought about removing the error message, but thought it still might be useful for users tracking down why they're getting an error.

[bpaul4]

What needs to be done here?

[dallan-keylogic]

I'm not sure---I copied that class from the tests for ReactionBase, which also has that TODO. I think I can strip out a significant amount of those methods for the test.