_load_for_executorch_from_buffer doesn't keep buffer alive

🐛 Describe the bug

When using _load_for_executorch_from_buffer, the python bindings do not appear to maintain a reference to the buffer passed in, but native code does. This means that if the buffer is GC'd, the native code will still use it. Python doesn't know that it's still a live reference.

It's likely that need to do something in the pybind or native code to mark that there are native references into they python buffer object. I have not tested this with the new pybind APIs, but I believe they use the same calls under the hood.

Repro:

def load_model(file_path):
    with pathmgr.open(
        file_path,
        "rb",
    ) as f:
        buffer = f.read()
        et_model = _load_for_executorch_from_buffer(buffer)
    return et_model

et_model = load_model(model_file_path)
output = et_model(inputs)

Wait a second or two, then run the model again...

et_model(inputs)

It may crash. ASAN will reliably catch the use after free.

Versions

N/A

Start at the _load_for_executorch_from_buffer Python binding and trace the pybind or native ownership handling described in the report. Reproduce the delayed second inference with ASAN. Done means the model remains safe to use after the original buffer goes out of scope, with no use-after-free detected.