feat: Move projectGroupName to projects.create()

[Luca Forstner (lforst)]

• Braintrust organizes projects into "project groups", and a user can have permission to create projects inside a group without being allowed to create projects anywhere else in the organization.
• A recent unreleased change added a projectGroupName option to initLogger, init, initDataset and Eval.
  When the named project didn't exist yet, it was created inside that group.
• The problem is that loggers resolve their project every time they start up, not just once.
  • Passing a group switches the backend from a cheap, cached lookup to an uncached "create or verify group membership" call that locks the whole group's database row.
  • In production that means every logger cold start, across every service logging into that group, waits on the same lock.
  • If the project already exists outside the group, or is later moved out of it, the backend rejects the call, so logging fails because of a permissions change rather than a code change.
• Creating a project is really a one-time setup step, so this PR takes projectGroupName back out of initLogger, init, initDataset and Eval.
  They now send the same requests as before the earlier change.
• The option now lives on the push and publish path instead: projects.create({ name: "my-project", projectGroupName: "my-group" }).
  • Previously projects.create() only took a project name or id, and braintrust push / project.publish() always created missing projects at the organization level.
  • Now those commands pass the group along when they register the project, so a missing project is created inside that group.
• The standalone bt CLI reads the same SDK project definitions, and feat: Create projects inside a project group on bt functions push bt#395 makes bt functions push pass the group along too.
• The earlier change hasn't been released, so removing the option from the logger, experiment and dataset entrypoints doesn't break anyone.