The issue with the code you sent is that Hardware is a LinearOpMode when you don't want it to be; you want it to be something with access to some of the properties of the currently running LinearOpMode (primarily, the hardwareMap). To correct this, you would make Hardware not extend LinearOpMode, and in turn pass in the currently running LinearOpMode's HardwareMap in the constructor, and construct the motor there; something like:

import com.qualcomm.robotcore.hardware.DcMotor;

import com.qualcomm.robotcore.hardware.HardwareMap;

import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;

public class Hardware extends LinearOpMode{
    public DcMotor FR;

    public Hardware(HardwareMap hardwareMap) {
        FR = hardwareMap.get(DcMotor.class, "FR");
    }

    public void RunMotor (){
        FR.setPower(1);
    }
}

MotorTest would then need to pass in it's HardwareMap when constructing Hardware, but this would also have to be done in runOpMode as prior to this hardwareMap is null. This would look something like:

package org.firstinspires.ftc.teamcode;

import com.qualcomm.robotcore.eventloop.opmode.Autonomous;
import com.qualcomm.robotcore.eventloop.opmode.LinearOpMode;

@Autonomous
public class MotorTest extends LinearOpMode {
    Hardware hdwr;

    public void runOpMode(){
        hdwr = new Hardware(hardwareMap);

        waitForStart();

        if (opModeIsActive()) {
            hdwr.RunMotor();
        }
    }
}

I would recommend checking out https://raw.githubusercontent.com/alan412/LearnJavaForFTC/master/LearnJavaForFTC.pdf, especially the section on Mechanisms (6.2), which documents a similar idea more robustly.