[enhancement] rationalize macros, builtins and stdlib functions namespace

### What's hard to do? (limit 100 words)

builtins are not organically discoverable by developer:
- they are under a (empty) root namespace: code completion will only list them if you know the prefix
- they can't be easily grepped from DSLX source distribution's `.x` files (as they are implemented directly in C++ using `FunctionBuilder`)

additionally there are currently two types of builtins function:
- macro-ish builtins that ends w/ `!` that act as syntax shorthand for that would be impossible/cumbersome to express in DSLX in a generic way (`zero!, `all_ones!`), have special runtime-only semantic (`trace_fmt!) or are direct pass-thru to codegen (`gate!`, `cover!`).
- regular builtins that act as regular function but require (or benefit) from IR "super power" for their concrete implementation (`update`, `range`, `zip/map`) and that sometime have (or could have) alternate stdlib implementation (`smulp`, `umulp`, `clz`).

Note: some operator (ex: `+`, `*`, `/`) also have alternative stdlib alternative implementation (`add`, `mul`, `iterative_div`) w/ different semantic on return type or trade-off in synthesis result.

### Current best alternative workaround (limit 100 words)

Carefully refer to the documentation, which list both: https://google.github.io/xls/dslx_std/

### Your view of the "best case XLS enhancement" (limit 100 words)

It would nice to have distinctions for the namespaces that are relevant to developers:
- bang`!` macros (syntax short hand, ast-only manupulations, codegen pass-thru)
- a single namespace for builtins and std functions (`std::`?) w/ placeholder `decl` for IR-only/`FunctionBuilder` implementation
```
#[ir_op(proto=ir_op_pb2.OP_SMULP)]
fn smulp(lhs: sN[N], rhs: sN[N]) -> (sN[N], sN[N]);
```