(feat): refactor how pagination properties are checked in fern check

[dsinghvi]

Introduces a better primitive for property paths are checked.

1. Easy to write a message like $response.hasNextPage points to a string but should point to a boolean instead
2. request + response validation build on the same schemas
3. validatePropertyInType invokers control the error message

return validatePropertyInType({
        typeResolver,
        file,
        path: getPathFromSelector(offsetPagination["has-next-page"]),
        resolvedType: resolvedResponseType,
        validate: ({ resolvedType }) => {
            const primitiveType = maybePrimitiveType(resolvedType);
            if (primitiveType !== "BOOLEAN") {
                return [
                    {
                        message: `"has-next-page" selector, ${offsetPagination["has-next-page"]}, does not point to a boolean property`,
                        severity: "error"
                    }
                ];
            }
            return [];
        }
    });
}

[amckinney]

Refactor looks great overall, nicely done!

We might be able to do something similar in the IR generator since we have to support a similar analogue abstraction there (i.e. the PropertyResolver).

That refactor isn't as necessary as this one, so we could also defer that until we actually unify fern check and fern ir since it otherwise might be a little wasteful.

[amckinney]

It looks like this would support any selector prefix - it doesn't actually validate that the user specified $response.

[amckinney]

nit: A variable would be nice for this since we use offsetPagination["has-next-page"] in a few places here.

We previously referred to them as propertyComponents, but we could probably just do path so it's consistent with the new validatePropertyInType signature.