Overload methods to accept Schema.SObjectType and Schema.SObjectField

Summary

When a custom object or field is removed from an org, it would be nice for a missed reference to be caught at compile-time. When passing strings to Query Lib, a missed reference will instead fail at runtime. Overloading Query Lib functions with Schema.SObjectType and Schema.SObjectField parameters would enable developers to be confident that their code is using existing objects and fields when it compiles.

Suggested Solution

Overload any functions that take an object type or field api name as a string to have another option to pass in Schema.SObjectType or Schema.SObjectField. For example from SOQL.Builder:

public Builder selectField(Schema.SObjectField field) {
    selectField(String.valueOf(field));
    return this;
}

and example usage:

SOQL soqlQuery = new SOQL.Builder(My_Custom_Object__c.SObjectType)
	.selectFields(new List<Schema.SObjectField>{
		My_Custom_Object__c.Id,
		My_Custom_Object__c.My_Custom_Field__c
	})
	.whereCondition(
		new Query.Condition()
			.equals(My_Custom_Object__c.Id, myId)
	)
	.build();

Alternative Solutions

No response

Start by locating SOQL.Builder methods that accept object or field API names as strings, then inspect Query.Condition handling for the same pattern. Check how Schema.SObjectType and Schema.SObjectField convert to existing string-based paths. Done means the relevant overloads accept these schema types while preserving current string behavior, with coverage for the example usage.