Incorrect Typespec Generation for Fields with Custom or Parameterized Ecto Types in Strukt

## Problem Description:
When defining a field with a custom Ecto type or a parameterized type in Strukt, the generated typespec for the field defaults to `any()` instead of the expected specific type (e.g., Ecto.UUID.t()). This issue may lead to less precise type checks and unexpected behaviors in development environments that rely on typespecs for static analysis or documentation purposes.

Example Code:

```elixir
defmodule Foo do
use Strukt

defstruct do
field :bar, Ecto.UUID
end
end
```
Expected: The typespec for `:bar` should be `Ecto.UUID.t()`.
Actual: The typespec for `:bar` is `any()`.

## Identified Issues:

### Incorrect Handling of value_type:
The `value_type` in the `typespec.ex` function is not being correctly passed as a quoted expression. This results in the type not matching the expected case for processing.

Relevant code:
https://github.com/bitwalker/strukt/blob/b2b853256b0360599d67ca9f44b361c2a2a75beb/lib/typespec.ex#L56
https://github.com/bitwalker/strukt/blob/b2b853256b0360599d67ca9f44b361c2a2a75beb/lib/typespec.ex#L141

### Failure in `defines_type?` Check:
The `defines_type?` function check always fails. This function, intended to verify if the current module defines a given type, is not feasible in current Elixir compiler. The docs of `defines_type?` say
> Checks if the current module defines the given type (private, opaque or not).
> This function is only available for modules being compiled.

Discussion related to this issue can be found here: [Getting the @type module attribute](https://elixirforum.com/t/getting-the-type-module-attribute/22163)
Relevant code: https://github.com/bitwalker/strukt/blob/b2b853256b0360599d67ca9f44b361c2a2a75beb/lib/typespec.ex#L152