Support Dialect provided StatementRenderers SPI.

A custom Dialect should be able to contribute statement rendering capabilities to allow for more divergent rendering strategies.

SPI outline:

interface StatementRenderer<T extends Visitable, SRC extends StatementRenderContext<T>>{

	Class<T> getStatementType();

	String render(T statement, SRC context);

	interface StatementRenderContext<T> {

	}
}

interface Dialect {

	// ...

	@Nullable
	<T extends Visitable> StatementRenderer<T, StatementRenderContext<T>> statementRenderer(Class<T> type);
}

Usage in custom implementation

public class MyDialect extends AbstractDialect {
    
    @Override
    public <T extends Visitable> StatementRenderer<T, StatementRenderContext<T>> 
            statementRenderer(Class<T> type) {
        
        if (type == Upsert.class) {
            return (StatementRenderer) new MyUpsertRenderer();
        }
        return super.statementRenderer(type);
    }
}
class MyUpsertRenderer implements UpsertStatementRenderer {
    @Override
    public String render(Upsert statement, UpsertRenderContext context) {
        // ...
    }
}

Start by reading the Dialect and AbstractDialect APIs, then trace how statements are currently rendered. Compare that flow with the proposed StatementRenderer and StatementRenderContext SPI. Done means custom Dialect implementations can provide renderers for statement types such as Upsert while existing rendering remains supported.