Host-qualify ghostel-project buffer identity for remote roots

[dakra]

Fixes #344.

Problem

ghostel-project derives its buffer identity via project-prefixed-buffer-name, which only uses the project root's basename. A local project ~/foo and a remote /ssh:user@host:~/foo therefore collide on *foo-ghostel*, and invoking ghostel-project from the remote project reused (and displayed) the local project's terminal instead of creating one on the remote host. The same host-blind prefix was used by ghostel--project-buffers, so identity-scoped ghostel-project-next/previous/list-buffers could cycle into the other host's buffers.

Fix

New helper ghostel--project-buffer-name: for local roots it returns the same *NAME-ghostel* as before (no behavior change); for remote roots it folds the TRAMP prefix into the name, e.g. *foo-ghostel@ssh:user@host*. The full method:user@host prefix is used rather than just the host, since different users or methods on one host are different environments. file-remote-p is purely syntactic, so no connection is opened. Both ghostel-project and ghostel--project-buffers use the helper, so creation, reuse, and cycling agree on the identity.

Plain M-x ghostel singleton behavior is unchanged (confirmed as intended in the issue discussion).

Tests

Four new elisp tests in test/ghostel-project-test.el: helper naming for local vs remote roots, the regression scenario itself (remote project must not reuse the local buffer), idempotent reuse of the remote buffer, and identity-scope separation in ghostel--project-buffers. make -j8 all passes.

Also verified live in a sandboxed Emacs session: a real local ghostel-project terminal plus a stubbed-spawn remote invocation yield two distinct buffers with distinct identities; re-running the remote call reuses the remote buffer and the local call still reuses the local one.