feat(ChatAuto)!: Single provider/name argument and prefer function arguments over envvars

[gadenbuie]

Fixes #90

This PR updates ChatAuto() to improve the experience for interactive use while leaving room for the developer-facing features of the previous implementation.

New provider_model first argument

The first change is to use a single argument and environment variable to specify the provider and model:

from chatlas import ChatAuto

# ❌ Before
ChatAuto(provider="openai", model="gpt-5")

# ✅ After
ChatAuto("openai/gpt-5")

The new argument, provider_model, is now first in the function signature, and we've moved system_prompt behind the * so that it must be named. The provider_model value has a corresponding envvar: CHATLAS_CHAT_PROVIDER_MODEL.

New argument/envvar precedence

The second biggest change in this function is to prioritize interactive ergonomics. Prior to this PR, ChatAuto() treated provider and model (now provider_model) as default values that were used if environment variables are not set.

# Before, inside ChatAuto
the_provider = os.getenv("CHATLAS_CHAT_PROVIDER", provider)
the_model = os.getenv("CHATLAS_CHAT_MODEL", model)

After this PR, we now only use env vars when function arguments are not provided. This sounds limiting, but it opens up a much better experience for interactive use without really blocking any developer-facing benefits.

This major change introduces a new flow:

1. provider_model and kwargs are always used if provided directly to ChatAuto().
2. CHATLAS_CHAT_PROVIDER_MODEL and CHATLAS_CHAT_ARGS are only used if not provided in the function call.

This means that interactive users never have to unset or manage environment variables. On the other hand, developers can now more easily insert their own env vars in front of chatlas's defaults, e.g. the following will consult MYAPP_PROVIDER_MODEL before chatlas's envvars, which was previously quite tricky to get right:

import os
from chatlas import ChatAuto

chat = ChatAuto(os.getenv("MYAPP_PROVIDER_MODEL"))

Prior to this, devs would have to temporarily overwrite chatlas's envvars with the values of their custom envvar to do the same thing.

Finally, the previous envvars and arguments are still used with a deprecation warning.

[cpsievert]

This sounds limiting, but it opens up a much better experience for interactive use without really blocking any developer-facing benefits.

Here's another way to motivate the change...

The prior approach was embracing the idea that "a sysadmin can override decisions made by the developer without any code changes". At the time that seemed like a useful thing, but you could also argue it's at best surprising and at worst dangerous. That is, if the developer has set a model, they've likely designed and tested only for that specific model, and may not even be aware that someone else could change the model without their input. With this new way, the developer has more control over whether the model is fixed or configurable.