Fix problems with local hosted plugins

[AndrMoura]

Currently, in the production environment, PostHog does not allow Virtual Machines, where plugins are executed, to communicate with a hosted service on the host.

Local addresses fail for the following snippet:

// fetch.ts @ raiseIfUserProvidedUrlUnsafe
for (const { address } of addrinfo) {
        // Prevent addressing internal services
        if (ipaddr.parse(address).range() !== 'unicast') {
            throw new FetchError('Internal hostname', 'posthog-host-guard')
        }
    }

and host.docker.internal fails here since it has no hostname:

// fetch.ts @ raiseIfUserProvidedUrlUnsafe
let addrinfo: LookupAddress[]
  try {
      addrinfo = await dns.lookup(parsedUrl.hostname, { all: true })
  } catch (err) {
      throw new FetchError('Invalid hostname', 'posthog-host-guard')
  }

Added host.docker.internal to the plugin service, so it can communicate with host backend models on localhost.

If a user is running, the plugins backend, locally, it must point to http://host.docker.internal:9612 to reach it.

[AndrMoura]

Adds a default network postlangto enable fast and reliable communication between PostHog-LLM and any plugin backend that is also going to be added to this network.

When a user sets up a plugin on the Data Pipeline page, if the plugin backend is running inside a Docker container, they should point directly to the service alias (e.g., http://flowdetect:9612/). host.docker.internal has too much overhead for intra-container communication.