Config: Remove legacy inbound/outbound/detours

[mmmray]

These things seem entirely undocumented, make it a hard error to set them.

[RPRX]

这些不像 transport，Xray 的文档中就没有出现过，可以直接删掉，不必 left for returning error

看起来我们正在执行 #1967 ，对 3 有什么想法吗，比如说底层传输那里要找到最终的 dial 简直是一坨，尤其是 UDP 实在太混乱了每次看都把我绕进去，根本记不住架构看一次痛苦一次，急需简化一下

[mmmray]

In the end, I am still new to the codebase, and do some superficial refactoring as I encounter issues. I think it will take a long time to warm up to this kind of work.

I found that when adding a new transport, a lot of new interfaces have to be added. I wish that instead of parsing JSON, building a protobuf struct from it, there is instead one config struct per transport and that's it. This is my personal vendetta. I haven't done any research on how to achieve this. Originally I said, I want to remove protobuf, but I don't think it's realistic anymore unless there is a decision to remove grpc API and replace it with some JSON/REST API.

Right now I am trying to compile infra/conf to wasm, in order to use it in some online "config validation" tool. Of course, I underestimated this. I need to strictly separate the struct definitions in infra/conf from any code that imports things like sys/unix.

I also noticed that there are wasm-related build tags in the code, but the codebase definitely does not compile to wasm at all.

Anyway, all of this is totally unrelated, but I might propose a PR to split up the config-related code so that some parts can be compiled separately. I don't know what exactly to do yet.

[RPRX]

I found that when adding a new transport, a lot of new interfaces have to be added. I wish that instead of parsing JSON, building a protobuf struct from it, there is instead one config struct per transport and that's it. This is my personal vendetta.

看来你也发现了当前的基础架构有多么 shit，据说是 java 的锅，我也想把 Xray-core 的基础架构改得简洁直观，让我们一起努力