fix(lint): infer void return type for block-bodied arrow functions

[crowlbot]

Problem

deno doc --lint raised a spurious missing-return-type diagnostic for an exported const initialized with a block-bodied arrow function, while the equivalent function expression was accepted:

export const a1 = () => {};        // ❌ missing-return-type (before)
export const b1 = function () {};  // ✅ ok

Both forms implicitly return void (or Promise<void> when async), so the lint should treat them identically. The arrow/function-expression discrepancy was reported in #823.

Fix

function_to_function_def already inferred void/Promise<void> for function expressions whose body has no value-returning return. This extracts that logic into a shared inferred_void_return_type helper and applies it to block-bodied arrow functions as well.

Behavior after the change is consistent across both forms:

source	inferred return
() => {} / function () {}	void
async () => {} / async function () {}	Promise<void>
() => { return 1; } / function () { return 1; }	none → missing-return-type (unchanged)
() => 1 (expression body returning a value)	none → missing-return-type (unchanged)

Expression-bodied arrows (() => 1) and bodies containing a value-returning return are deliberately left alone — inferring those would require type-checking the body.

Test

Adds tests/specs/function_const_return_type_inference.txt, covering arrow vs. function-expression parity for void inference, async inference, variable-annotation satisfaction, and the value-returning cases that still require an explicit annotation.

Fixes #823

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}