minor: SessionStateBuilder::with_default_features ergonomics

[milenkovicm]

Is your feature request related to a problem or challenge?

Just a small note about ergonomics of SessionStateBuilder, as I spent some time to figure out why:

    let session_state = SessionStateBuilder::new()
        .with_table_factory("DELTA_TABLE".to_string(), Arc::new(DeltaTableFactory {}))
        .with_default_features()
        .build();
    let ctx = SessionContext::new_with_state(session_state);

    ctx.sql("create external table dt stored as delta_table location './data/append_table/'")
        .await
        .unwrap()
        .show()
        .await
        .unwrap();

fails with Execution("Unable to find factory for DELTA_TABLE")?

Apparently ordering of with_ methods matters as

    let session_state = SessionStateBuilder::new()
        .with_default_features()
        .with_table_factory("DELTA_TABLE".to_string(), Arc::new(DeltaTableFactory {}))
        .build();

will work as expected.

Apparently, with_default_features will override table factories if called last (like I would usually do):

pub fn with_default_features(self) -> Self {
        self.with_table_factories(SessionStateDefaults::default_table_factories())
            .with_file_formats(SessionStateDefaults::default_file_formats())
            .with_expr_planners(SessionStateDefaults::default_expr_planners())
            .with_scalar_functions(SessionStateDefaults::default_scalar_functions())
            .with_aggregate_functions(SessionStateDefaults::default_aggregate_functions())
            .with_window_functions(SessionStateDefaults::default_window_functions())
            .with_table_function_list(SessionStateDefaults::default_table_functions())
    }

Describe the solution you'd like

Would it make sense from ergonomic perspective to make with_default_features() rather than with_default_features(self) and force it to be the first statement in the builder.

Describe alternatives you've considered

It can stay as it is, I might be pedantic, but would make sense to document it (which I personally would probably miss)
or don't override/join values if already there.

Additional context

No response

[alamb]

I agree it would be great not to override any existing table providers 👍

[alamb]

Seems like a good first issue to me

[irenjj]

take