Optimize sequence_gen and uniform_sequence_gen to reduce template instantiation depth

[tenpercent]

Summary

• Use compiler builtin __make_integer_seq for sequence_gen and uniform_sequence_gen
• Optimize sequence_merge using direct concatenation for small cases
• Reduces template instantiation depth from O(N) to O(1)

Motivation

The recursive sequence_gen_impl creates deep template chains for large sequences, increasing compile time and memory usage.

Why It Works

The compiler builtin __make_integer_seq generates the entire integer sequence in a single step internally, without recursive template instantiation. This reduces instantiation depth from O(N) to O(1), significantly cutting compile time for large sequences.

Additionally, sequence_merge now uses direct concatenation for 2-3 sequences instead of recursive merge, reducing overhead.

Test Plan

• Added 4 unit tests for sequence_gen with custom functors
• Waiting for full CI

PR Stack

This PR is part of the build time optimization effort (issue #3575). All PRs now target develop independently:

#	PR	Description	Status
1	#3585	sequence_gen with __make_integer_seq	This PR
2	#3628	generate_identity_sequences + named functors	New (replaces #3588, #3589)
3	#3590	container_concat optimization	Updated
4	#3596	O(1) pack expansion rewrites	Updated
5	#3600	TensorDescriptor/TensorAdaptor lambda elimination	Updated

Tracking issue: #3575

[shumway]

Do you want to add unit tests for this, or just rely on the tests of all the code that depends on this? If it's easy to add unit tests, that's generally better, but I'm also fine with moving fast to cut down compilation times.

[shumway]

I like these specializations. It will be interesting to get a survey of the code to see how often the specializations are used and if these four smallest cases are the most impactful ones.

[tenpercent]

I'm using the build traces to drive the optimizations. Maybe removing the unused code is one other aspect which could help with parsing times

[tenpercent]

Do you want to add unit tests for this, or just rely on the tests of all the code that depends on this? If it's easy to add unit tests, that's generally better, but I'm also fine with moving fast to cut down compilation times.

let's move fast, in case something important breaks CI will catch it, tests also need maintenance and let's see how much of the metaprogramming is left after the initial sprint