Remove some CreateProgram() reacharounds in 134 TTNN ops and CreateBuffer() reacharound in allocate_buffer_on_device()

[kmabeeTT]

Ticket

#17199

Problem description

We need to use host_api.hpp functions to support Light Metal tracing today (feature), they are what are instrumented for capture + replay of workloads. With this change, I am able to trace + replay some TTNN simple unit tests with unary + binary ops, nice.

What's changed

• Update ~134 ops to use CreateProgram() API instead of Program constructor. Around 100 ops were already using CreateProgram() so this just updates the rest.
• Found one usage of Buffer::create() which reaches around CreateBuffer(), so update function allocate_buffer_on_device() to use BufferCreate().

Checklist

• All post commit CI passes
• Blackhole Post commit CI passes (if applicable)
• Model regression CI passes (if applicable)
• Device performance regression CI passes (if applicable)
• (For models and ops writers) Full new models tests CI passes (if applicable)
• New/Existing tests provide coverage for changes

[ayerofieiev-tt]

Thank you for opening this, Kyle!
I propose to find time to chat about this during the upcoming f2f.
My priority is to resolve the path quickly to unblock you.

Here are my thoughts:

• This approach goes against the direction we’ve taken since closing the Metal API effort.
• The existing host APIs don’t fully cover the actual surface of the Metal API—see the scope in tt_metal/api/metallium.
• As a result, TT-NN makes many direct calls to objects:
  • In some cases, there are alternative free functions, e.g., cq.enqueue_write_buffer(..) vs EnqueueWriteBuffer(..).
  • In other cases, these calls should be removed entirely, e.g., device->push_work(...).
  • Some calls don’t have host API equivalents, such as buffer->address(), buffer->device(), buffer->size(), and many others across device, buffer, program, kernel, and allocator.
• This means that users of Metal continue to make direct calls to objects, and that won’t change in the foreseeable future.
• Consequently, the current approach to tracing above the actual API is error-prone:
  • There’s no guarantee that developers won’t call real objects directly.
  • This PR can’t fundamentally change that. Immediately after merging, someone could create an OP that directly instantiates a program or makes a direct call to cq.
• A functional API isn’t a requirement for enabling tracing. See this existing example: Graph Tracing.
• The team is actively working to improve the Metal API surface to unblock our top priority—distributed:
  • Extracting and cleaning up abstractions for device, command_queue, and allocator.
  • Reducing the API surface, hiding implementation details, and employing PIMPL.
  • This work will also pave the way for mocked/traced/custom allocators, devices, command queues, and offline builds.

CC @nsmithtt @sminakov-tt