feat(csharp): add pagination helper methods to C# SDK generator

[Swimburger]

This feature works, but the code is still a little rough and needs some cleaning.

• The new HttpPagerEndpointGenerator generates pager methods that use the main endpoint methods for users to paginate over items in a paginated endpoint.
• AsIs/Page.Template.cs holds a list of items in a single page
• AsIs/Pager.Template.cs has a public abstract Pager<Item> class for a user to interact with, and two internal implementations OffsetPager and CursorPager`. The bulk of the logic to paginate is stored within these implementations, and the remaining parts are passed into the pagers as delegates.

⚠️ Assumption: For cursor-based pagination, the cursor is assumed to be a string. This is probably correct in 95% of cases, but that's just a guess. Does the cursor type need to be configurable?

⚠️ Big change: The generator thus far assumes that each endpoint generates one method on a client. This PR changes that so that an endpoint generator can generate multiple methods. For generated SDKs, this isn't too big of a change, but this also affects generated snippets and references. There's some code duplication to quickly get snippets and references to work as expected with this pager variation method for the endpoint

1. Should we stick to one method per endpoint to reduce the amount of change in this generator and downstream dependencies? Or
2. Should we push forward on an endpoint with multiple methods and refactor the generator at a larger scale for this to be supported seamlessly?

[github-actions[bot]]

🌿 Preview your docs: https://fern-preview-c360b9f1-650a-46ff-bc3a-99fc70f3cefc.docs.buildwithfern.com/learn

[Swimburger]

Decisions:

• Make original method private/internal
• Only make pager public and use the original method name
• Produce snippets/references only with pager name

[Swimburger]

The mockResponse is generated incorrectly in ListWithExtendedResultsAndOptionalDataTest and ListWithExtendedResultsTest. The mockresponse JSON should have the data property. The list within data is optional so that's fine, but there should be a data: {} property since that isn't optional in Fern definition.

[Swimburger]

Improvements:

• Support for different types in cursor pagination
• Support for int and long in offset pagination
• Initialize request if null before passing request to setCursor and setOffset
• Initialize nested properties towards cursor and offset property.

For initializing towards cursor and offset property, I assume the types don't have required fields and initialize an empty instance using ?? = new().

I'm worried if one of these types does have a required field, at which point the compiler will complain.

[Swimburger]

I added a shallow clone using the record with {} feature. Future versions of C# may include a DeepClone feature for records.