fix(vivado): Derive softmax layer config name from activation attribute

[HamzaEzzRa]

Description

Vivado (and Vitis, since it reuses the same pass) backend's SoftmaxFunctionTemplate hardcodes the generated config struct name as lowercase softmax_config{index}, while SoftmaxConfigTemplate derives it from the layer's activation attribute. For standalone keras.layers.Softmax in Keras v2, that attribute is 'Softmax' (capital), so the generated parameters.h declares Softmax_config{index} but myproject.cpp calls softmax_config{index}, generating uncompilable code.

Activation('softmax') and inlined Dense(..., activation='softmax') work since they carry the lowercase attribute. A simple fix for the standalone Softmax is to make SoftmaxFunctionTemplate derive the config name from the same attribute as SoftmaxConfigTemplate. This matches how Quartus and Catapult backends handle softmax, and how all the other activations are named. Keras v3 seems unaffected, since it always sets the attribute to lowercase 'softmax', regardless of how softmax is called.

Type of change

• Bug fix (non-breaking change that fixes an issue)

Tests

Extended test/pytest/test_softmax.py.

Both test_softmax and test_softmax_skipped take a new softmax_impl parametrization (['activation', 'standalone']) that builds the softmax op with either keras.layers.Activation('softmax') or keras.layers.Softmax, respectively. Before the SoftmaxFunctionTemplate fix, the standalone cases would fail on the Vivado backend at C++ compile time with an undeclared softmax_config{index}.

After the suggested fix, both paths pass. Quartus and Catapult were unaffected, as their function templates already derive the config name from the layer attribute.

Test Configuration:

Similar pytest configuration as the existing test_softmax.py tests, with the added softmax_impl parametrization.

pytest test/pytest/test_softmax.py

Checklist

• I have read the guidelines for contributing.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have installed and run pre-commit on the files I edited or added.
• I have added tests that prove my fix is effective or that my feature works.