fix: avoid decimal overflow in portfolio statistics alpha

[Romazes]

Description

PortfolioStatistics computed alpha in decimal. When the annual performance is capped at decimal.MaxValue and the benchmark term is negative, the subtraction overflows:

BaseResultsHandler.GenerateStatisticsResults(): Error generating statistics packet System.OverflowException: Value was either too large or too small for a Decimal.
   at System.Number.ThrowOverflowException(String message)
   at System.Decimal.DecCalc.ScaleResult(Buf24* bufRes, UInt32 hiRes, Int32 scale)
   at System.Decimal.DecCalc.DecAddSub(DecCalc& d1, DecCalc& d2, Boolean sign)
   at System.Decimal.op_Subtraction(Decimal d1, Decimal d2)
   at QuantConnect.Statistics.PortfolioStatistics..ctor(SortedDictionary`2 profitLoss, SortedDictionary`2 equity, SortedDictionary`2 portfolioTurnover, List`1 listPerformance, List`1 listBenchmark, Decimal startingCapital, IRiskFreeInterestRateModel riskFreeInterestRateModel, Int32 tradingDaysPerYear, Nullable`1 winCount, Nullable`1 lossCount)

Alpha is now computed in double and cast back with SafeDecimalCast, the same way the information and Treynor ratios already are.

Related PR(s)

#8256 fixed the same overflow for the information and Treynor ratios.

Related Issue

N/A

Motivation and Context

Seen in a live deployment. A cash deposit more than doubled the account value, so one daily return was about +156% and the annual performance hit the decimal cap. From the next day on, every statistics update failed with the error above, 45 times in 2.5 days, until the algorithm stopped.

Requires Documentation Change

No

How Has This Been Tested?

• New PortfolioStatisticsTests.PortfolioStatisticsDoesNotFailWhenAlphaExceedsDecimalRange: fails on master with the stack above, passes with the fix.
• QuantConnect.Tests.Common.Statistics: 379 of 379 passed.
• C# BasicTemplate* regression algorithms: 40 of 40 passed, so their expected alpha did not change.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>