Updates to require by string RFCs (#14)

* Updated rfcs

* Removed @ requirement

* Updated alias

* Added a space

* Undid @ for paths

docs/new-require-by-string-semantics.md

@@ -48,7 +48,7 @@ Modules can be required relative to the requiring file's location in the filesys
 
 If we are trying to require a module called `MyModule.luau` in `C:/MyLibrary`:
 ```lua
-local MyModule = require("./MyModule")
+local MyModule = require("MyModule")
 
 -- From C:/MyLibrary/SubDirectory/SubModule.luau
 local MyModule = require("../MyModule")
@@ -57,7 +57,7 @@ local MyModule = require("../MyModule")
 local MyModule = require("../MyLibrary/MyModule")
 ```
 
-Relative paths must begin with `./` or `../`, which denote the directory of the requiring file and its parent directory, respectively. Disallowing implicit relative requires (`require("Foo")` resolves to `require("./Foo")`) disambiguation of how requires will run. When a relative path does begin with one of these prefixes, it will only be resolved relative to the requiring file. If these prefixes are not provided, path resolution will fallback to checking the paths in the `paths` configuration variable, as described later.
+Relative paths may begin with `./` or `../`, which denote the directory of the requiring file and its parent directory, respectively. When a relative path does begin with one of these prefixes, it will only be resolved relative to the requiring file. If these prefixes are not provided, path resolution will fallback to checking the paths in the `paths` configuration variable, as described later.
 
 When a require statement is executed directly in a REPL input prompt (not in a file), relative paths will be evaluated in relation to the pseudo-file `stdin`, located in the current working directory. If the code being executed is not tied to a file (e.g. using `loadstring`), executing any require statements in this code will result in an error.
 

docs/require-by-string-aliases.md

@@ -34,7 +34,7 @@ Or even a sub-module:
 local createElement = require("@Roact/createElement")
 ```
 
-Aliases are overrides. Whenever the first component of a path exactly matches a pre-defined alias, it will be replaced before the path is resolved to a file. Alias names are also restricted to the charset `[A-Za-z0-9.\-_]`. We restrict the charset and make them case insensitive because we envision alias names to be primarily used as package names, which tend to be case insensitive and alphanumeric. 
+Aliases are overrides. Whenever the first component of a path exactly matches a pre-defined alias, it will be replaced before the path is resolved to a file. Alias names are also restricted to the charset `[A-Za-z0-9.\-_]`. We restrict the charset and make them case insensitive because we envision alias names to be primarily used as package names, which tend to be case insensitive and alphanumeric. They also must be preceded by an `@` symbol. 
 
 ### Package management
 
@@ -230,7 +230,7 @@ This way, each subproject directory can contain its own source code, dependencie
 
 This allows us to refer to other subprojects like this, regardless of the exact location of the requiring file in `large-luau-project`:
 ```lua
-local subproject1 = require("com.roblox.luau/subproject-1")
+local subproject1 = require("@com.roblox.luau/subproject-1")
 ```
 ### Roblox Specifics
 In the Roblox engine, a similar aliasing system could be implemented. Assuming a central package management system were available, a Roblox Script could contain local Roact = require("@Roact"), and everything would "just work".
@@ -251,7 +251,7 @@ Rather than defining paths/alias maps in an external configuration file, we coul
 local Roact = require("@Roact")
 
 -- Same as this:
-local Roact = require("@C:/LuauModules/Roact-v1.4.2")
+local Roact = require("C:/LuauModules/Roact-v1.4.2")
 ```
 
 Some potential issues with this approach: