Issue title: fn vs fngen
 Issue body: I see fns as different to fn-generators. When I declare a fn, I am painting memory with code:

`````zig
fn add(a: u32, b: u32) u32 {  
    return a + b;
}
`````

When I declare a fn-generator, I lay down a template for how fns can be generated on-request at compile time:

`````zig
fn add(a: var, b: var) @TypeOf(a) {  
    return a + b;
}
`````
This can be used to paint a whole universe of `add` functions (`add_u32_u32`, `add_f64_i16`, ...).

(Being new to Zig,)? I find it hard to distinguish the two when reading code. 

Can more experienced Zig programmers effortlessly tell at a glance if the declaration you are reading corresponds to a runtime address you can query with &? 

If a fn which has comptime params or anytype params is a fn generator, not a fn, why not introduce it with a different keyword? 

Maybe there could be a requirement that every _fn_ which has no runtime body, ie for which `@sizeOf(@TypeOf(_functionName_)) == 0`) needs to be declared with a keyword different from `fn`, maybe:

`````zig
fngen add(a: var, b: var) @TypeOf(a) {  
    return a + b;
}
`````

It would certainly highlight to newbies that something interesting is going on...
 Comments: 
 Comment 0: > (Being new to Zig,)? I find it hard to distinguish the two when reading code.

Why do you need to? The intention is that you shouldn't need to.

> Can more experienced Zig programmers effortlessly tell at a glance if the declaration you are reading corresponds to a runtime address you can query with &?

You can take the address of comptime functions too. So this isn't a meaningful difference.
Furthermore, with e.g. IFUNCs, then there is sort of more than one address for each function.
 Comment 1: Some (minor?) reasons to distinguish between the two is that they have observable different behavior:

`````zig
fn genericFn(a : var) void {}
fn reifiedFn(a : u32) void {}
test("different beasts") {

// A pointer to a generic fn must be const, and it has no Frame...
var fnPtrToGenericFn = genericFn; // error: variable of type 'fn(var) var' must be const or comptime
const frameOfGenericFn = @Frame(genericFn); // error: @Frame() of generic function

// ...vs reified:
var fnPtrToReifiedFn = reifiedFn; // ok
const frameOfReifiedFn = @Frame(reifiedFn); // ok

// Address of generic?
var addressOfGenericFn = &genericFn; // error: variable of type 'fn(var) var' must be const or comptime
const addressOfGenericFn = &genericFn; // Ok, but... really? Let's look at it:
warn("&genericFn = {}\n",.{addressOfGenericFn}); // error: pointer to size 0 type has no address

// Address of reified:
var addressOfReifiedFn = &reifiedFn; // ok, and really ok, let's look at it:
warn("&reifiedFn = {}\n",.{&reifiedFn}); // really ok "reifiedFn = fn(u32) void@7ff77b7f900"

}
`````

(The `@thisFn` proposal might come in handy in this context, https://github.com/ziglang/zig/issues/5113#issuecomment-622977895)

But the major reason for me is "no hidden control flow", I want to understand what the code I write and read does, and see a major difference between these two which I need to understand in order to "read the code". 
 Comment 2: > ```zig
> warn("&genericFn = {}\n",.{addressOfGenericFn}); // error: pointer to size 0 type has no address
> ```

to me this suggests that we should print something special here: although `&generic_fn` is defined, `@ptrToInt(&generic_fn)` is not.
 Comment 3: So you cannot pass a ptr-to-a-generic_fn to a C function for the C function to invoke as a callback, but you can do that with a ptr to a non-generic-fn. A difference worth being aware of when reading code?
 Comment 4: > So you cannot pass a ptr-to-a-generic_fn to a C function for the C function to invoke as a callback, but you can do that with a ptr to a non-generic-fn. A difference worth being aware of when reading code?

Passing a C function would require a function with `callconv(.C)` which is its own restriction.
 Comment 5: 
`````zig
test("Yet another difference: "){genericFn();reifiedFn();}

// error: comptime parameter not allowed in function with calling convention 'C'
fn genericFn(comptime a: u32) callconv(.C) void { }
// allowed
fn reifiedFn(         a: u32) callconv(.C) void { }

`````
 Comment 6: AFAIK It's not possible to ever accidentally get this wrong. The compiler will always catch it. Distinguishing from normal functions is not hard - if a parameter is comptime or var, you can't make a runtime pointer to it.  But you wouldn't want to, because it's signature doesn't match any runtime pointer type.  You couldn't pass it to a function or put it into a table because there's no way to write the signature of that function or the type of that table.
 Comment 7: I find it only slightly confusing to have to look deep into the function signature to see if it is comptime or not, but I find that the _need_ to do so is greatly diminished by the compile-time code generation capabilities of Zig.   Consider C11's much weaker `_Generic`.   That does not have any call site-visible differences from normal calls either.
{'source': 'GithubIssues', 'repo_name_with_owner': 'ziglang/zig', 'issue_id': 611228885, 'repo_stars': 16982.0}